Re: LCWD comments

On Thu, 1 Jul 2010, Krzysztof Maczy�~Dski wrote:
> 
> [a] http://www.w3.org/TR/2009/WD-eventsource-20091222/
> 
> 0. In [a]:
> > The W3C Web Apps Working Group
> It's either "WebApps" or "Web Applications" according to the charter.

Fixed.


> 1. [a] references HTML5 which is unlikely to go to Rec any time soon. 
> What path do you envision following to resolve this?

Waiting. There's no rush to get to REC.


> 2. In [a]:
> > HTTP 302 Found, 303 See Other, and 307 Temporary Redirect responses 
> > must cause the user agent to connect to the new server-specified URL, 
> > but if the user agent needs to again request the resource at a later 
> > point, it must return to the previously specified URL for this event 
> > source.
> Does it include only requesting a representation of the resource using 
> the same EventSource object, the same browsing context, or globally (as 
> long as the UA remembers having requested it before)? Is this consistent 
> (especially for 303) with HTTP semantics?

Clarified.


> 3. In [a]:
> > Any other HTTP response code not listed here, and any network error 
> > that prevents the HTTP connection from being established in the first 
> > place (e.g. DNS errors), must cause the user agent to fail the 
> > connection.
> I'm unsure whether it doesn't violate semantics of some HTTP codes 
> already defined. But it surely imposes limits on what future codes may 
> indicate, flying in the face of this extensibility point. All that this 
> spec should say about the potentially coming unknown is that semantics 
> of other codes must be applied as required for them.

That doesn't seem like it would lead to great interoperability in the 
face of errorneous servers.


> 4. text/event-stream uses text before / which is inappropriate and 
> should be application. Entities of type text must be, at least as the 
> last resort, feasible for rendering to the user as text (which not any 
> sequence of octets is, e.g. text/html, but application/msword).

text/event-stream can be rendered to the user, it's just text.


> 5. In [a]:
> > formats of event framing defined by other applicable specifications 
> > may be supported
> What is event framing?

A structure for demarking events.


> Additionally, are we going to have „other applicable specifications” 
> extension point everywhere?

It's what pretty much everything on the Web uses, from IP all the way to 
JS, so apparently yes.


> For the moment it's just a beast dwelling in the HTML5 spec, tolerated 
> until it gets its extensibility story straight, but if it's going to 
> affect other specs in this way, the TAG should certainly have a look.

I don't understand. This is how all specs are extended. Are you just 
referring to it being explicit? It seems better to be explicit rather than 
leaving things implied like most specs do.


> 6. Section 10 of [a] seems something new in W3C's LCs. What is the story 
> behind specifying requirements on finalization (note that this name is 
> better, since "garbage collection" looks like limiting this behaviour to 
> environments with a GC) and some rules stating when a spec should 
> include them?

The story is that it is needed in this case so as to define behaviour that 
is interoperably implementable.


> Has there been any architectural discussion about it?

What is "architectural discussion"?


> [b] http://www.w3.org/TR/2009/WD-webstorage-20091222/
>
> 7. In [b]:
> > The term "JavaScript" is used to refer to ECMA262, rather than the 
> > official term ECMAScript, since the term JavaScript is more widely 
> > known.
> The term "JavaScript" already refers to a proprietary implementation of 
> ECMAScript. A confusion should not be entrenched further just because 
> it's common. Clarity will be appreciated by intended readers of the 
> spec, of whom knowledge of this distinction can be safely assumed. The 
> term is unused anyway.

This is just part of the boilerplate used in specs that are really 
sections of the WHATWG Web Apps 1.0 spec published through the WebApps WG.


> 8. In [b]:
> > To mitigate this, pages can use SSL.
> Please change to TLS which is the standard name.

Fixed.


> 9. [b] states more precise requirements on scripts running in the 
> context of an HTMLDocument than otherwise. Should some of them apply 
> more widely?

I don't understand the question.


> [c] http://www.w3.org/TR/2009/WD-workers-20091222/
> 
> 10. In [c]:
> > the MIME type of the script is ignored
> This is a new spec. It shouldn't be plagued with such idiosyncratic 
> legacy mechanisms.

It's a new spec that has to work with existing deployed content.


> 11. In [c]:
> > there is no way to override the type. It's always assumed to be 
> > JavaScript.
> This is a violation of orthogonality for no real benefit.

The benefit is simplicity.


> 12. In [c]:
> > If there are any outstanding transactions that have callbacks
> What's a transaction, when has it got a callback?

Added a reference.


> 13. Why does [c] define ErrorEvent instead of reusing DOMError?

Primarily because DOMError is not an event.


> Besides, it uses a misnamed attribute "filename" and suboptimally 
> spelled "lineno".

Not sure what you mean. These are based on legacy names used in the 
window.onerror platform feature.


> 14. In [c]:
> > Thus, scripts must be external files with the same scheme as the 
> > original page: you can't load a script from a data: URL
> Why impose this restriction?

So that we can do cross-origin shared workers in the future.


> I suggest allowing workers to be instantiated with Function objects 
> (whatever this may be in language bindings, given positive resolution of 
> 11) as well. Including workers directly inline seems natural in many 
> scenarios.

What's the use case?

We wouldn't be able to use a Function object, since that would have all 
kinds of cross-thread implications. We could use a string, but Gears had 
that API and it went basically unused.


> 15. Why using URI fragments is not allowed when instantiating workers? 

What would they mean? (Disallowing them now means we might be able to use 
them if necessary later.)


> If it remains so, the spec should say that used URIs MUST be absolute 
> (keeping unchanged the behaviour in the other case as error recovery).

Why?


> 16. In [c]:
> > The DOM APIs (Node objects, Document objects, etc) are not available 
> > to workers in this version of this specification.
> I understand this as not being forbidden if an implementation provides 
> such an extension. However, those APIs would operate on nodes floating 
> in the air, unrelated to any document possibly opened.
>
> 17. Isn't there already something like WorkerLocation specced?

How do you mean?

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