[whatwg] A few hints on html5 -- part 2

[Ian Hickson]

On Tue, 16 Dec 2008, Calogero Alex Baldacchino wrote:
> 
> The removeEventSource() method is provided to remove one instance of a 
> source (one matching URL) per invocation, but no way is defined to know 
> whether other instances are yet listed, or if the operation succeeded. 
> Maybe such method could return a boolean value telling whether the 
> operation was successful, so that, i.e., all matching URLs could be 
> removed at once in a simple iteration calling the method until it 
> returns "false". Maybe a "remove all" method could be considered too.

The model used here is similar to addEventListener/removeEventListener. 
The actual list of event listeners, or event sources in this case, is not 
exposed, so that different scripts can reuse the same mechanism for their 
features without clashing with other scripts. If you want to keep track of 
what has been added, you can do so by wrapping the addEventSource (or 
addEventListener) method.


> I guess a single RemoteEventTarget can list several time the same remote 
> source to take advantage of more than one connection (maybe non-http) to 
> fetch different resources and/or to ask for different server-side 
> computations in parallel; however, it might be helpful to define either 
> a mechanism to remove a precise source (i.e. passing an index or the 
> alike, not just the URL) instead of removing a source on a "per enter 
> position" basis (that is, the first encountered is removed, as could be 
> thought) or a precise choice algorithm (i.e., skipping an "active" URL), 
> since without neither a precise targeting nor a precise algorithm a 
> somewhat user agent could remove the wrong url upon request, and so 
> closing for instance a connection with a pending get operation: one of a 
> RemoteEventTarget message event handlers could receive an "end event" 
> and try and close its connection, but the implementation, by mistake, 
> could remove a source URL used by another handler waiting for a 
> response, or the method could be invoked from a piece of code outside 
> any handler, and so the choice might become more difficult. Otherwise, 
> an algorithm should be defined to switch the communications from a 
> closed source to another still active.

We don't really want to optmise for the case of the same URI being used 
twice, as that is an unlikely scenario other than when there is a bug -- 
thus the current behavior.


> According to the previous hint, let me suggest the following:
>
> - a streamed event should be associate to a numerical index [...]

Since this is an edge case that doesn't really have a use case, I don't 
really want to add features to handle it.


> a "remove source as possible task" is a task delegated to remove the 
> source URL from the list of event sources and to close the related 
> connection as soon as any pending event is completely received and 
> dispatched to every listening handler and no message has been post to 
> the remote server (otherwise wait for the response event); a "remove 
> source immediately task" is a task performing the same operation but 
> without waiting for pending events: as soon as the task is executed, the 
> event source is eliminated.

This can be done now; just wait for that last event and then unregister 
the event source. If there's an infinite stream of events, and thus no 
last event, then it doesn't matter if you didn't get a whole event. Thus, 
the current model.

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'