<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2800.1498" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff background="">
<DIV><FONT face="Courier New" size=2></FONT><FONT face="Courier New"
size=2></FONT><FONT face="Courier New" size=2></FONT><FONT face="Courier New"
size=2></FONT><FONT face="Courier New" size=2>Hello,</FONT></DIV>
<DIV><FONT face="Courier New" size=2>I recently saw your draft specification and
the sections related to the event-source element. This is really fantastic stuff
and I wish I had been paying attention much sooner!</FONT></DIV>
<DIV><FONT face="Courier New" size=2></FONT> </DIV>
<DIV><FONT face="Courier New" size=2>I apologize for this very lengthy post, but
I have a strong interest in this sort of technology. Several years ago I worked
at a company called KnowNow where I spent a lot of time implementing browser
based libraries and applications in JavaScript to do almost exactly what this
definition of event-source describes. Since then, I've spent a lot of
engineering time designing and building servers for large scale subscription and
notification services at various companies. Doing that work taught me a lot
about the balance between flexibility, ease of coding and efficiency.
</FONT></DIV>
<DIV><FONT face="Courier New" size=2></FONT> </DIV>
<DIV><FONT face="Courier New" size=2>I'd like to find out how I can be an active
contributor in this area, both in terms of discussions as well as in terms of
development. I've also included a brain dump of my thoughts - also posted to my
blog: </FONT><FONT face="Courier New" size=2><A
href="http://korrespondence.blogspot.com/2005/06/whatwg-and-event-source-design.html">http://korrespondence.blogspot.com/2005/06/whatwg-and-event-source-design.html</A> I
realize this could easily be interpreted as a johnny-come-lately ivory tower
post, but I hope that's not how it's viewed - I'm really very interested in
participating and collaborating in any way I am able to.</FONT></DIV>
<DIV><FONT face="Courier New" size=2></FONT><FONT face="Courier New"
size=2></FONT> </DIV>
<DIV><FONT face="Courier New" size=2>Anyway, here's the post...</FONT></DIV>
<DIV><FONT face="Courier New" size=2>=====</FONT></DIV>
<DIV><FONT face="Courier New" size=2></FONT><BR><FONT face="Courier New"
size=2>The <a href="http://www.whatwg.org/">WhatWG</a> is a set of
individuals and reprentatives of 'browser manufacturers' that are defining the
evolution of HTML markup to help Web application developers. They call
themselves 'unofficial', but most people realize that rough consensus and
working code can create more momentum than 'official' channels.<BR><BR>They have
recently described an extension to HTML allows a Web browser to receive a stream
of events from a server - the <a
href="http://www.whatwg.org/specs/web-apps/current-work/#the-event-source">event-source
tag</a>. This is a wonderful concept and very similar to work done by
KnowNow, mod-pubsub and others over the past few years. From my experience with
these other approaches, I know that truly amazing things will happen when this
becomes commonplace and trivial to use. <BR> <BR>I had looked at the WhatWG
when it first started, but soon stopped following their development. From
reading the current draft of their description of this HTML extension, I can
forsee several technical issues and now I wish I had stuck with monitoring their
development in order to contribute to this section. Hopefully it's not too
late.<BR><BR>There are several technical issues and design approaches that are
interesting, but I can't find much background or discussion of these
alternatives, so I may be covering old ground with this post.<BR><BR>The
different areas I am interested in are:<BR> - connecting elements, event
streams and event handlers<BR> - format and definition of event
streams<BR><BR>1) connecting elements, event streams and event handlers<BR>From
the section "9.1.1. The event-source element" the approach is to introduce a new
element. I'd like to consider whether more than one event-source element is
allowed, and also consider whether simply introducing new attributes on existing
elements is easier and feasible. <BR>If a document is allowed to have more than
one event-source element then the client app will have to deal with either
multiple connections or combining multiple event-sources on one connection while
delivering events to the corresponding event-source element event handler. If
multiple connections are supported, then the client application could saturate
the capability of the client machine and could even be considered a 'poorly
behaved' client on the shared network.<BR><BR>An alternative to a new element
would be to add new attributes, for example:<BR> <p
event-src="/my/stocks/amzn/" onMessage="handleQuotes()" /><BR><BR>I suggest
using onMessage rather than onEvent to distinguish between network based
messages and application based events (e.g. connection-opened,
connection-closed-by-client, connection-closed-by-server, etc). I realize that
some people feel web developers would want these to look identical, but many
years of experience across the software industry has shown that they are simply
different beasts and making that explicit actually helps the developer. The
onEvent handler could be used for connection events on the event-source outside
the actual messages within that stream.<BR><BR><BR>2) format and definition of
event streams<BR>Section "9.1.3 Processing model" defines how connections should
be handled, and it's great to see this detail, especially arounds failure modes,
closed connections, etc.<BR><BR>This section indicates that client should
re-open connections after a small delay if they were closed in a successful
situation. This section should consider persistent connections (i.e. keep-alive)
and distinguish reply-level response codes from connection-level operations. For
example, rather than saying "HTTP 200 OK responses with the right MIME type,
however, should, when closed, be reopened after a small delay.", it may be
better to say something like "The retrieval of an event-source that completes
successfully (it has the correct content-type and an HTTP 200 OK response status
code) should be tried again after a short delay." In addition, the client should
continue to obey the appropriate cache-control response headers - this allows
the server to dynamically influence the interval that the client retrieves
future events (beyond a static value placed in other attributes on the
event-source element). This would be useful in the HTTP 204 No Content situation
described in this section as well.<BR><BR><BR>Section "9.1.4. The event stream
format" defines a new MIME type and new syntax for the browser to process. This
section also has the most detail of the interaction between events and the
application logic. I don't want to sound too negative, but this is the section
that needs the most help. Several years ago, when I was at KnowNow, I spent a
lot of time implementing browser based libraries and applications in JavaScript
to do almost exactly what this definition of event-source describes. Since then,
I've spent a lot of engineering time designing and building servers for large
scale subscriptions and notifications at various companies. Doing that work
taught me a lot about the balance between flexibility, ease of coding and
efficiency. <BR><BR>There are three aspects of this event stream that I'm
concerned about </FONT></DIV>
<DIV><FONT face="Courier New" size=2> - the meaning of the event stream
resource itself, </FONT></DIV>
<DIV><FONT face="Courier New" size=2> - the framing of individual messages
within that event stream </FONT></DIV>
<DIV><FONT face="Courier New" size=2> - how to handle re-processing the
event stream in different situations (errors, page refresh by the user,
etc)<BR><BR>The proposal I have is to consider the src= attribute on the
event-source element as referencing a 'collection of messages'. As to the
framing of individual messages, when retrieving this collection of messages via
HTTP, I suggest using the multipart/mixed or multipart/digest MIME type.
Individual parts can then have their own content-type and developers can decide
which suits their needs - a simple name/value pair approach like form data (not
my favorite), javascript object definitions like JSON, etc. See
http://www.w3.org/Protocols/rfc1341/7_2_Multipart.html for details.<BR><BR>I
realize that one use-case or scenario is for mobile devices and message size is
a concern. I think it may be possible to follow the pattern of multipart/mixed
but create a terse syntax that follows the same capabilities of multipart/mixed
with respect to compression (transfer-encoding, gzip, etc), formats
(content-type) and localization (character-encoding).<BR><BR>For each message,
the WhatWG event-source definition introduces specific names used for
controlling routing to event handlers but it seems trivially easy to define an
approach that isn't specific to this new syntax. Specifically, the Event and
Target names could be replaced.<BR><BR>My proposal is to define the each message
in the event streams to be similar to a request, except that no possibility of a
response from the client exists. This provides for each message to have a URI
that indicates it's target and a method that indicates the event type
(post/put/delete).<BR><BR>For example, rather than an HTTP response
of:<BR><BR>200 OK<BR>Content-type:
application/x-dom-event-stream<BR>Content-length: NNNN<BR>\n<BR>Event: stock
change\n<BR>data: YHOO\n<BR>data: -2\n<BR>data: 10\n<BR><BR><BR>Use a more
generic event stream like<BR><BR>200 OK<BR>Content-type: multipart/mixed;
boundary=msg_boundary<BR>\n<BR>\n<BR>--msg_boundary<BR>POST
/event-handler/stocks HTTP/1.0<BR></DIV>
<DIV><FONT face="Courier New" size=2>Content-type:
text/javascript-object</FONT></DIV>
<DIV><FONT face="Courier New" size=2>Content-length: NNNN<BR>\n<BR>{symbol:
"YHOO", delta: -2, value: 10}<BR></FONT>--msg_boundary<BR>PUT
/event-handler/stocks/YHOO HTTP/1.0<BR>Content-type:
text/javascript-object</FONT></DIV>
<DIV><FONT face="Courier New" size=2>Content-length: NNNN<BR>\n<BR>{delta: -2,
value: 10}<BR>--msg_boundary</FONT></DIV>
<DIV><FONT face="Courier New" size=2></FONT><FONT face="Courier New"
size=2></FONT> </DIV>
<DIV><FONT face="Courier New" size=2>There may be 'issues' with adding the
request-line in a multipart/mixed response, but defining a 'multipart/message'
might work for that. And if people don't like HTTP/1.0 in the request-line, we
could define a 'simple notification protocol' as SNP/1.0</FONT></DIV>
<DIV><FONT face="Courier New" size=2></FONT> </DIV>
<DIV><FONT face="Courier New" size=2>That last thing I'll mention has to do with
re-processing the event stream. Re-processing an HTML page from start to end
generally works. However, re-processing an event stream from start to end is
generally not going to work well. The situations to consider are when the user
manually refreshes the page and when the retrieval of the event stream completes
successfully. When the user manually refreshes the page, the src= attribute will
be the same as when the page was previously retrieved, but should the events be
the same as previously retrieved, or should they be messages from that moment
forward? And when the the retrieval of messages succeeds and the client waits a
few moments before retrieving the next set from the very same URI, should that
next set be the same messages again?</FONT></DIV>
<DIV><FONT face="Courier New" size=2></FONT> </DIV>
<DIV><FONT face="Courier New" size=2>This is a tricky area and I'm sure there
are several ways to approach this. I'll write more later...</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face="Courier New" size=2></FONT> </DIV>
<DIV><FONT face="Courier New" size=2></FONT> </DIV>
<DIV><FONT face="Courier New" size=2></FONT> </DIV></BODY></HTML>