W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2012

Re: Lazy Blob

From: Glenn Adams <glenn@skynav.com>
Date: Thu, 2 Aug 2012 09:58:53 -0600
Message-ID: <CACQ=j+dBOvbC8ypePNj8bsLvr58kab9ekbHRG6n4LBO4pobZNw@mail.gmail.com>
To: Florian Bösch <pyalot@gmail.com>
Cc: Robin Berjon <robin@berjon.com>, Glenn Maynard <glenn@zewt.org>, WebApps WG <public-webapps@w3.org>, Jungkee Song <jungkee.song@samsung.com>
On Thu, Aug 2, 2012 at 9:51 AM, Florian Bösch <pyalot@gmail.com> wrote:

> On Thu, Aug 2, 2012 at 5:45 PM, Glenn Adams <glenn@skynav.com> wrote:
>
>> No it hasn't. If you want a real world use case it is this: my
>> architectural constraints as an author for some particular usage requires
>> that I use WS rather than XHR. I wish to have support for the construct
>> being discussed with WS. How is that not a real world requirement?
>>
>
> Your particular use-case of content/range aquisition over WS requires a
> particular implementation on the server in order to understand the WS
> application layer protocol. This particular implementation on the server of
> yours is not implemented by any other common hosting infrastructure based
> on any kind of existing standard. You should specify this particular
> protocol standard to be used on top of WS first before you can even discuss
> how your custom implementation of this protocol justifies enshrining it in
> a browser standard.
>

All WS usage requires a particular (application specific) implementation on
the server, does it not? Notwithstanding that fact, such usage will fall
into certain messaging patterns. I happened to give an example of two
possible message patterns and showed how the proposal under discussion
could address those patterns. It is not necessary to marry my proposal to a
specific sub-protocol on WS in order to provide useful functionality that
can be exploited by applications that use those functions.
Received on Thursday, 2 August 2012 15:59:45 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:54 GMT