Re: sockets

Hi, Jonathan-

Jonathan Chetwynd wrote (on 9/6/08 5:10 AM):
> 
> having difficulty understanding "We are aligning around the
> work being done in the WebApps WG and HTML5 WG to ensure broader
> interoperability.
> 
> if it's dropped?

Rather than defining it ourselves, we are going to be reusing more
general work that's being done in HTML5 and WebApps.

A bit of background: sockets was included as an wrapper interface for
exiting socket interfaces already deployed on mobile phones,
particularly in Java-based frameworks.  The security model was already
worked out in the JSRs (Java specifications), and there were different
mechanisms already in place in different environments, but there was no
way to access this functionality within the standard DOM.  So, this
interface simply served as a generic API to expose functionality that
already existed in the target environment: the mobile phones.

I still contend that it was a good piece of functionality to have, and
it was a reasonable way to approach it for mobile devices.  However,
it's also true that it wasn't yet well-specified enough for desktop
browsers (which were not the target implementors for SVG 1.2 Tiny).
Since the plan was for SVG 1.2 Tiny to serve as the core of the
language, with SVG 1.2 Full to follow, this concerned browser vendors,
who were wary of the SVG specs introducing this functionality without
adequate security models defined in the SVG spec itself (as opposed to
in JSRs).  Obviously, for a desktop spec like SVG 1.2 Full, the SVG WG
would have more clearly defined the security model.

But at that time, 4 years ago, browser vendors weren't ready to
entertain the notion of socket interfaces in Web technologies.  The
mobile and desktop worlds were still further apart then than they have
since become, though the trend was pretty clearly toward convergence.

In the meantime, things that SVG had had for a while (through Adobe's
plugin, with the get/setURL methods) were beginning to be more widely
used in HTML as well; IE had long before created the XMLHttpRequest
method, and it was copied by the other desktop browsers.  When the
buzzword AJAX was coined for this sort of client-server chatter, it took
off, and that became the typical way to do such things.  Out of that
came the realization that a socket interface (properly specced) was, in
fact, a good idea.

SVG was just ahead of the curve.  At the time the WG specced that out,
though there was clear market need, this work wasn't being done anywhere
else in W3C.

However, now that desktop browser vendors have cottoned to the notion of
such functionality, it is being developed more closely according to
their needs and with greater scrutiny towards security, which is good.
The point was never for the functionality to be defined in SVG, but just
available to it.  With more people working on a solution that has broad
acceptance, the SVG WG is happy to reuse that more generalized solution.
 It's easier for authors and users and implementors for us all to be
using exactly the same technology in just the same ways across SVG,
HTML, etc.

I hope that clears it up for you?


> I read elsewhere that websockets also has issues, breaking standards
> already set...

I'm confident that any problems that are being discussed now will be
resolved to the satisfaction of the browser implementors.  Standards are
most useful for establishing interoperability and providing authors and
users with clear and precise guidelines to functionality that they can
use.  Standards are always subject to being updated (or even changed)
when the overall environment, or the use cases and requirements, change.
 Stability is a goal, but never a perfect constraint.


> in what public space is this being discussed if not here?

Right now, the HTML5 WG.  Personally, I'd prefer it were being specced
out in a different WG, such as the WebApps WG, which has a nascent spec
for just such functionality, and which is clearly and specifically
chartered to do this.  I'm less happy about it being in HTML5, because
it may be too HTML-specific there.


> given the relevance of SVG to games and hence sockets, presumably this
> is the place?
> but it's very quiet on that front...

I don't want to discount that discussion of this (or any other) subject
could happen in the SVG IG, but if it does, it should be in a structured
way, with a clear agenda, endpoint, and goal.  If there are several
people who think that we should pursue this matter, then we  can put it
on the agenda.

Personally, I don't see a need for it.  This is being addressed by
different WGs already, and there's already been much SVG WG discussion
on the matter.

The scope of the SVG IG is intended for focused discussion, use case and
requirement deliverables, and community building.  Questions like this
that pertain to work already in the spec are better asked on www-svg.
The SVG IG is meant to drive future functionality of SVG, establish best
practices, and so forth.

Finally, the SVG IG already has a lot of things on its platter, as
detailed in the wiki.  I don't want to build up a huge wishlist of
discussion topics before resolving the ones we already have.  That's a
path to failure.


Regards-
-Doug Schepers
W3C Team Contact, WebApps, SVG, and CDF

Received on Saturday, 6 September 2008 15:11:53 UTC