- From: Sangwhan Moon <sangwhan@iki.fi>
- Date: Tue, 7 Jan 2014 13:50:36 +0900
- To: "<public-websignage@w3.org>" <public-websignage@w3.org>
Putting aside the question of "who is this document for"... (e.g. is it for UA implementors, web developers, or a document for the sake of having a document? - I'll send a follow up mail on this, the draft mail I wrote needs some serious diplomatic sandpaper) On Tuesday, January 7, 2014 at 12:35 PM, Futomi Hatano wrote: > > > 3/ Reception of emergency information > > > ^We are considering WebSocket or HTTP PUSH for this. ̄ Why not but have a look at : > > > > > > XEP-0127: Common Alerting Protocol (CAP) Over XMPP : <http://xmpp.org/extensions/xep-0127.html>http://xmpp.org/extensions/xep-0127.html > > > PubSubHubbub: ie http://alert-hub.appspot.com/ for http://www.google.org/crisisresponse/ > > > > > > > > Yeah, right. If signage terminal is capable of XMPP, it can be used. > > Even thought this profile is for web-based signage, It will be good if we can provide several candidates. > > > > Currently, the popular browsers support only HTTP/HTTPS (XHR/Server-Sent Events) > and WebSocket protocol. > If we use XMPP, we have to use it on HTTP/HTTPS or WebSocket. > That is, CAP over XMPP over WebSocket, for example. > In fact, WebRTC adopt this approach for signaling. > > If we provide XMPP or PubSubHubbub in the doc, > we should mention the difference of the communication layers. Although there is no standard defining a XMPP API within a browser context - there is [1] this which can be used to build a polyfill of some sort. I'm not entirely convinced about XMPP, since the fault tolerance in disaster scenarios is quite likely very low without support for something like XEP-0174. (Sadly, I have seen one implementation of XEP-0174 - not the most widely adapted standard…) (Additionally, XMPP is a pretty heavy protocol - but that's my subjective point of view) One thing I would like to note is that there have been a lot of discussion about emergency announcements from a TV / digital billboard which IMHO is missing one very important point - transport under infrastructure instability. Most of the proposals I've seen in the last couple years have been dismissing this little point, assuming the network (or a central server) is available - which is probably not always the case. One idea would be to use a mixture of NSD and WebRTC's RTCDataChannel to make a serverless peer to peer network - which could be a bit more fault tolerant, but until it's prototyped and proven to work I wouldn't really put people's life at stake on this approach. I've been personally experimenting with a old school FM transmitter/Web Audio/FSK modulation for fun as a "networkless one way browser to browser data transmission mechanism" feasibility experiment (even when everything fails - analog radio still works!), but this obviously needs bigger forces to sign off to be of any use. (Think of [2] this, but with higher complexity) Sangwhan [1] http://strophe.im/strophejs/ [2] http://www.youtube.com/watch?v=w6lRq5spQmc
Received on Tuesday, 7 January 2014 04:51:08 UTC