Re: Re[2]: Contribution for "Proposed initial draft of "Architecture and Requirements for Web-based Signage Player - Emergency Information Profile"

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