New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Are camelCase codec parameters useful at all? #689

Closed
ibc opened this Issue May 8, 2017 · 15 comments

Comments

Projects
None yet
5 participants
@ibc
Contributor

ibc commented May 8, 2017

Currently EDGE does not use camelCase RTP codec parameters (it uses packetization-mode rather than packetizationMode and so on). Also, there is no proper "conversion rule". In SDP land we have parameters such as sprop-maxcapturerate, useinbandfec and L that are mapped to spropMaxCaptureRate, useInbandFec and l forcing the implementation to keep a map of them (as here).

But, at the end, not even EDGE implements the ORTC camelCase syntax. Given that having a different naming provides zero benefit here, why not keep untouched the SDP naming?

Also, as @aboba pointed:

Since Edge implements both WebRTC 1.0 and ORTC, developers found it very confusing to convert SDP codec parameters back and forth from camelCase.

(definitely I'm one of those "confused" developers...).

@taylor-b

This comment has been minimized.

taylor-b commented May 8, 2017

I agree with this. The camel case naming makes the idealist part of me happy, but practically speaking, ORTC is definitely expected to be used to connect with remote endpoints that use SDP, so using names that match SDP would make everyone's lives easier.

@ibc

This comment has been minimized.

Contributor

ibc commented May 8, 2017

Also, forcing camelCase means that the ORTC draft needs to be updated at every time a new codec parameter is defined somewhere else.

@robin-raymond

This comment has been minimized.

Contributor

robin-raymond commented May 12, 2017

This feels like we are in bad way on either decision. We need W3C expert to comment on what should we do....

@aboba

This comment has been minimized.

Contributor

aboba commented May 12, 2017

@dontcallmedom Is there official W3C guidance on this?

@ibc

This comment has been minimized.

Contributor

ibc commented May 12, 2017

We need W3C expert to comment on what should we do....

We have IETF RFCs defining useinbadfec or packetization-mode. WebRTC draft does not need to define them but just include/use. In ORTC draft, instead, we need to define and describe each parameter because we use different naming.

@robin-raymond

This comment has been minimized.

Contributor

robin-raymond commented May 12, 2017

I assume you meant RFCs... we made things proper camel but Edge didn't do it... so what is the guidance in this situation? change the spec? or change the implementation? Should we follow the exact RFC names?

@ibc

This comment has been minimized.

Contributor

ibc commented May 12, 2017

IMHO ORTC should follow exact RFC names, as Edge does. Otherwise, when combining both, WebRTC and ORTC (for example when coding a shim) you end with hacks like this.

@dontcallmedom

This comment has been minimized.

Member

dontcallmedom commented May 15, 2017

Here is the guidance on camelCasing property names. Of course, there can be justified exceptions to that guidance, but seeing that there are cases where the SDP names contains hyphens (packetization-mode, sprop-maxcapturerate), these would be very awkward at best to use in JavaScript without changes - in which case, converging back on camel-casing would seem reasonable.

@ibc

This comment has been minimized.

Contributor

ibc commented May 17, 2017

Indeed I would like that both, WebRTC and ORTC, use camelCase everywhere. But when it comes to deal with codec parameters (defined in so many RFC's), having to keep a mapping is problematic. Just consider the real fact that Edge does not use camelCase parameters (as defined in ORTC) but keeps the original naming. I've implemented two ORTC<->SDP shims and, again, I've found it terribly problematic.

As told above, having camelCase in ORTC means that the ORTC spec must define all the existing codec parameters. This is not a good idea. Some ORTC implementations may want to add custom codecs or parameters not supported by ORTC itself. If so, pointing to the related RFC would not be enough. Instead, a custom parameter mapping should also be provided.

Honestly I see zero advantage in forcing camelCase for RTP parameters in ORTC, no matter what the JS / W3C guidelines state.

@ibc

This comment has been minimized.

Contributor

ibc commented May 17, 2017

Or, at least, ORTC and WebRTC should use the same naming for the same parameters, and it's not like WebRTC is gonna adopt camelCase at all...

@ibc

This comment has been minimized.

Contributor

ibc commented Jul 23, 2017

Hi, is there any update on this? what does the final decision depend on? If I create a PR for this, would it have any chance to be merged?

@aboba

This comment has been minimized.

Contributor

aboba commented Jul 25, 2017

@ibc I would support such a PR.

ibc added a commit to ibc/ortc that referenced this issue Jul 25, 2017

- Don't use camelCase for parameters but keep SDP naming (fixes w3c#689
…).

- Remove trailing space at the end of lines.
@ibc

This comment has been minimized.

Contributor

ibc commented Jul 25, 2017

@ibc I would support such a PR.

Here it is: #733 :)

@ibc

This comment has been minimized.

Contributor

ibc commented Jul 25, 2017

OK, here the PR for "no-camelCase": #734

@ibc

This comment has been minimized.

Contributor

ibc commented Jul 25, 2017

And here the editorial PR: #735

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment