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

On Tue, 7 Jan 2014 13:50:36 +0900
Sangwhan Moon <sangwhan@iki.fi> wrote:

> 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)  

It's an important question.
We haven't discussed that point.
I look forward your follow up mail!


> 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.

Right.
That's because telecommunication is not tolerant to disasters
regardless of whether it's wired or wireless (WiFi, 3G, LTE, etc.).
We should not assume telecommunication can cover all disaster situations.
Telecommunication is completely helpless especially at devastated areas after a disaster.
But telecommunication is available until just before a disaster even at devastated areas.
Besides it can provide area-specific information, unlike broadcasting such as TV and radio.
So it's helpful for disaster prevention or damage limitation.

Diversity of the ways to provide emergency information is important .
Telecommunication is just one of them.
So I think we may assume the network is available when we discuss the Emergency Information Profile.


> 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 don't know NSD. What is it?
I'm not sure a serverless P2P network is helplul at a disaster situation,
because the fact remains that it is telecommunication.
I think P2P is helpful for smartphones rather than signs.

> 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

Interesting. [2]
It's possibly useful for sending information in a personal device to a sign.

Cheers,
Futomi

--
Newphoria Corporation
Chief Technology Officer
Futomi Hatano
--
futomi.hatano@newphoria.co.jp
http://www.newphoria.co.jp/

Received on Tuesday, 7 January 2014 06:58:20 UTC