- From: Glenn Adams <glenn@skynav.com>
- Date: Thu, 2 Aug 2012 11:09:39 -0600
- To: Ian Hickson <ian@hixie.ch>
- Cc: WebApps WG <public-webapps@w3.org>
- Message-ID: <CACQ=j+ck39pMP5h7u19UFY3qtXH6ViTtNn+0C0uoTioX+a2HHg@mail.gmail.com>
On Thu, Aug 2, 2012 at 11:01 AM, Ian Hickson <ian@hixie.ch> wrote: > On Thu, 2 Aug 2012, Glenn Adams wrote: > > > > > > Sorry, I was vague. What I mean is what user-facing problem is it that > > > we're trying to solve? > > > > see DAR's initial message in this thread; bringing WS into scope doesn't > > change the problem statement, it merely enlarges the solution space, or > > keeps it from being unnecessarily narrow > > Do you have a link to a specific message? I went through the archives and > couldn't find any e-mails in this thread that came close to describing a > use case for anything, let alone anything that would be related to > persistent bi-directional full-duplex communication with a remote server. > I was referring to [1]. [1] http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0264.html While that message does not specifically refer to a full-duplex comm path, it states the general problem in terms of "It is increasingly common that data may flow from a server to an in-browser page, that may then pass that data on to another in-browser page (typically running at a different origin). In a many cases, such data will be captured as Blobs." It goes on to describe a solution space oriented towards XHR as the comm path. It occurred to me that the same problem could apply to WS comm path patterns, which is why I suggested enlarging the solution space to include WS.
Received on Thursday, 2 August 2012 17:10:30 UTC