Re: [ACTION-43] (sdp related objects and global namespace) - way forward

On Fri, Jun 15, 2012 at 12:55 PM, Harald Alvestrand <harald@alvestrand.no>wrote:

> On 06/15/2012 12:07 PM, Adam Bergkvist wrote:
>
>> On 2012-06-15 08:52, Harald Alvestrand wrote:
>>
>>> On 06/14/2012 04:54 PM, Adam Bergkvist wrote:
>>>
>>>>
>>>>
>>>>>> 3. Come up with a new shorter name that less general and keep the
>>>>>> objects in the global namespace.
>>>>>> * PeerSessionDescription
>>>>>> * PeerMediaDescription
>>>>>> - SessionDescription doesn't mean that much to the average web
>>>>>> developer so we could go with Media instead to make the usage
>>>>>> clearer.
>>>>>>
>>>>> Neither 1 nor 3 move them out of the global namespace.
>>>>>
>>>>
>>>> I don't see moving them out of the global namespace as the only
>>>> solution to this problem (even though that's how the action was
>>>> formulated). We're already putting a lot of stuff in the global
>>>> namespace with PeerConnection prefixes. Renaming was also discussed
>>>> during the meeting.
>>>>
>>>
>>> There's a reason why the action was recorded at it was; I thought that
>>> once it was pointed out that we could reduce our pollution footprint, it
>>> was obvious that we should do so.
>>>
>>
>> Sure, but IceCandidate and SessionDescription are only two of the names
>> we introduce in the global namespace (others are DataChannel,
>> PeerConnectionErrorCallback, ...). I think we need to be consistent or
>> determine that some objects are special enough to be treated differently.
>>
>> I simply wanted to present our alternatives and get some comments from
>> the people who had opinions about this on the meeting.
>>
>
> Tommy promised to provide more information on this, but apparently stuff
> that doesn't have constructors isn't accessible from the global JS
> namespace, so doesn't pollute in the same way - the names are only visible
> internally in the IDL specifications.
>
> We do provide constructors for PeerConnectionEvent,
> PeerConnectionIceEvent, MediaStreamTrackEvent, MediaStreamEvent and
> DataChannelEvent.
>
> Dom, do all events require constructors?
>
> MediaStream provides a constructor, but only for making a mediastream out
> of track lists.
> getUserMedia seems to be the only other name we expose in the getUserMedia
> spec.
>
>
>
Note that I'm speaking with my WebKit/developer hat on here.

The events (and callbacks) we have implemented right now can NOT be created
from JavaScript and thus can only be created from native code. In
my opinion that means that the names does not pollute the global name space.

My opinion is that if something has clearly defined members and they are
expected to be all used it should be a class.
That also helps the type checking since the interfacing code doesn't have
to check everything, only the type of the object.

Also when assigning values to the attributes some syntax checking can be
done and appropriate action taken.
For example var foo = new SessionDescription('..', '..');
foo.type = 'the quick brown fox'; // This might throw an exception

/Tommy

-- 
Tommy Widenflycht, Senior Software Engineer
Google Sweden AB, Kungsbron 2, SE-11122 Stockholm, Sweden
Org. nr. 556656-6880
And yes, I have to include the above in every outgoing email according to
EU law.