- From: Giuseppe Pascale <giuseppep@opera.com>
- Date: Fri, 25 Nov 2011 10:02:33 +0100
- To: WebIntents <public-web-intents@w3.org>, "Greg Billock" <gbillock@google.com>
On Wed, 23 Nov 2011 21:56:31 +0100, Greg Billock <gbillock@google.com> wrote: > There's a difference between ensuring that there's a way to >> communicate (which should be covered here), and ensuring a requirement >> for a specific transport. >> > > Yes. As we've discussed elsewhere, there's nothing in the API proposal to > forbid returning a persistent connection handle (MessagePort), allowing > the > client and service to exchange further messages. (And in fact we hope > that > ends up facilitating a wide range of use cases.) But it leaves the issue > of > what protocol is exchanged over such a channel unspecified. > > I think what Paul is suggesting is that if there are particular protocol > translations or definitions to establish for that which would be helpful, > they not be in scope for the Web Intents API, but be considered > separately. I agree with the statement that a detailed work on the messaging protocol can be discussed separately. But I also think that most of the people that will look at this second step will probably share 90% of the issues. So I was wondering if it could make sense to at least explore the options and try to come up with some recommendations/best practices. Of course this doesn't necessarily needs to be done here, but I would say it should be done by one group (maybe DAP?). And the joint effort is not about writing a universal protocol but sharing experiences on how different protocol can be built on top of intents to try to converge to similar design patterns. > That would also allow them to be composed more generally with other > mechanisms we may dream up in the future to establish, share, or persist > messaging channels in the web platform. If we decide that Web Intents is > a > good API to establish such channels, that would be great, and perhaps > reduces the size of the problem to be solved (or rather, more fruitfully > segments it). > > More generally, this connection discovery mechanism allows us to envision > a new class of web applications which could exploit protocol translations > for MessageChannel (i.e. FTP, SSH, JDBC). could you expand on this? what do you mean by "protocol translations for MessageChannel" > Some cursory looking around > didn't show any W3C effort around this; perhaps UPNP is a good place to > start. :-) (I know very little about it.) well the W3C web&tv IG is interested in this, but is just an IG, we need a WG to do some actual work :) -- Giuseppe Pascale TV & Connected Devices Opera Software
Received on Friday, 25 November 2011 09:03:09 UTC