- From: Alex Russell <slightlyoff@google.com>
- Date: Mon, 6 Jan 2014 10:54:55 -0800
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: Konstantinov Sergey <twirl@yandex-team.ru>, "www-tag@w3.org List" <www-tag@w3.org>
- Message-ID: <CANr5HFULPxRFOp_=0d0N+AMnyJf5E+yW1XXAo+qwP5xjV0FnNA@mail.gmail.com>
On Mon, Jan 6, 2014 at 5:41 AM, Anne van Kesteren <annevk@annevk.nl> wrote: > On Wed, Dec 18, 2013 at 7:56 PM, Alex Russell <slightlyoff@google.com> > wrote: > > On Wed, Dec 18, 2013 at 4:46 AM, Anne van Kesteren <annevk@annevk.nl> > wrote: > >> I don't see why it would be really. > > > > We can imagine the API being standardized and the transport iterating > > underneath it. That's just good layering. > > Sure. > > > > For instance, if some system decides to deliver push notifications from > the > > SMS baseband protocol, should we, as the web platform, decide that's a > bad > > thing for them to be doing? I say "no", not because I don't want full > specs, > > but because precluding opening this power to developers seems foolhardy > at > > the level of an API contract. > > > > If we want to recommend that this WG open up a new effort to specify > > transport and message formats, great. But their API doesn't require it. > We > > shouldn't either. > > Their API is somewhat tied to the transport layer though. It does not > hand you a URL for nothing... I don't really see how else you could do > that kind of bridging either. > I admit the bit where they hand a URL in is a bit of a fudge. I noted somewhere (can't' recall where) that they should have a generic (string? JSON?) payload and let apps do as they will (modulo size limits for the payload). But with that problem of generality solved, the overall thing becomes transport agnostic, and I should point out, with respect to the underlying message delivery system, started that way. This is a non-issue WRT their current draft, IMO.
Received on Monday, 6 January 2014 18:55:54 UTC