RE: How can we implement UPnP service communication with intents?

Clarke Stevens wrote: 
> I'm still thinking about what level the intents should be (or if we care).
I think that in itself can be a long debate, which I'm not in a hurry to get
into. My bad for bringing up that distraction.

> However, we do have to consider the user experience. When a user is
sitting
> in front of a television the expected experience is that a volume-up
> command followed by a second volume-up command are extremely likely to
> mean volume-up on the same device. Maybe this is managed in the
> application, but if we don't consider this "persistent" relationship, we
are
> bound to make mistakes in the interface design.
Yes. That's a top priority in my mind too. If I understand correctly, what
Rich is proposing (and I agree with him) is to use the messaging channel to
maintain that persistent relationship. I imagine the same channel can be
used to support UPnP eventing as well.

- Cathy.

> 
> On 11/30/11 6:17 PM, "Rich Tibbett" <richt@opera.com> wrote:
> 
> >Cathy.Chan@nokia.com wrote:
> >> Rich Tibbett wrote:
> >>> I actually feel that the only absolute requirements on UAs would be
> >>>to
> >>> a.) listen for (via DNS-SD/SSDP discovery mechanisms) and emulate
> >>>discovered services as virtual Web Intents and b.) define a standard
> >>>channel  for these types of virtual services so the UA can relay
> >>>information on to  these  services via HTTP when they are connected
> >>>to a web app.
> >>
> >> That's a very good starting point.
> >>
> >>> The following is the flow I'm envisioning...
> >>>
> >>> The UA sends out a multicast DNS request asking for current
> >>>Intent-based  services (or an SSDP Search request) and then receives
> >>>back some devices  available (the service type is TBD but in this
> >>>example we call it  '_intents._tcp'
> >>> that has some well-defined TXT-record syntax for Intents). e.g.:
> >>>
> >>>   >  nslookup -q=any "_intents._tcp.local."
> >>> # START OF FIRST RECORD
> >>>      TV2._http._tcp.local.
> >>>                     priority = 0, weight = 0, port = 80, host =
> >>>10.0.0.231
> >>>      TV2._http._tcp.local
> >>>                     text = "action=http://foo.com/device/mute"
> >>> "path=/tv/mute"
> >>>      TV2._http._tcp.local
> >>>                     text = "action=http://foo.com/device/volume"
> >>> "path=/tv/volume"
> >>>      TV2._http._tcp.local
> >>>                     text = "action=http://foo.com/device/channel"
> >>> "path=/tv/changechannel"
> >>> # END OF FIRST RECORD
> >>> # ...etc
> >>>
> >>
> >> If multiple actions from the same device are mapped to different
> >>intents,  wouldn't the user be asked to pick the TV the first time he
> >>wants to change  volume, and then again when he wants to change the
> >>channel [for the first  time]? Would it make more sense for the intent
> >>to be associated with the TV  itself? I know this is just an example,
> >>but the underlying question
> >>remains:
> >> what's the level at which the intents should be defined?
> >
> >The level of abstraction is entirely up to the defined action type. The
> >messaging transformation - from web app to virtual web intent to HTTP
> >service and back - would remain consistent.
> >
> >Here's another example at a different abstraction level:
> >
> > >  nslookup -q=any "_intents._tcp.local."
> ># START OF FIRST RECORD
> >     TV2._http._tcp.local.
> >                    priority = 0, weight = 0, port = 80, host =
10.0.0.231
> >     TV2._http._tcp.local
> >                    text = "action=http://dahut.io/tv/" "path=/"
> ># END OF FIRST RECORD
> ># ...etc
> >
> >The action 'http://dahut.io/tv/' defines a more complex message channel
> >structure that allows for muting, volume control and channel changing.
> >
> >>
> >>> The UA then adds each intent service discovered to the index of
> >>>available  Web Intents and assigns each of these intents the
> >>>well-defined type of  'application/octet-stream+web_intent'.
> >>>
> >>> A web page requests one of the intent verbs and connects to one of
> >>>these  virtual intents (which may be the device discovered above or
> >>>another  device/service from elsewhere):
> >>>
> >>> var channel = new MessageChannel();
> >>> var intent = new Intent('http://foo.com/device/volume',
> >>> 'application/octet-stream+web_intent', channel.port2);
> >>> navigator.startActivity(intent);
> >>>
> >>> Then the web page can send messages to the chosen device/service via
> >>>the
> >>> channel:
> >>>
> >>> port1.onmessage = function(msg) {
> >>>     if(msg.data.action=='connected') {
> >>>       port1.postMessage({'action': 'mute', 'value': '1'});
> >>>     }
> >>> };
> >>>
> >>
> >> This is somewhat related to my question above. In your example, the
> >>activity  was started with the volume intent, but the message being
> >>sent is for a mute  action. Is that a typo or is it how you envision
> >>it to work - that you can  send actions other than the intended one
> >>once the message channel has been  established?
> >
> >This was a typo in the original email :( The example should have been
> >the following (or whatever message format the
> >'http://foo.com/device/volume' action comes to define):
> >
> >channel.port1.onmessage = function(msg) {
> >     // do something with msg
> >
> >     // set volume to 20/100ths.
> >     channel.port1.postMessage('20');
> >};
> >
> >>
> >>> The UA will then relay this posted data to the device via HTTP
> >>>according to  a  well-defined rule for handling
> >>>'application/octet-stream+web_intent'
> >>>data
> >>> via the MessagePort mechanism:
> >>>
> >>> GET 10.0.0.231:80/tv/volume HTTP/1.0 ...
> >>> [blank line here, followed by message body]
> >>> [{'action': 'mute', 'value': '1'}]
> >>>
> >>> The receiving device will then interpret this message or transform
> >>>it for  sending on to the real device (since in this model, we could
> >>>have service  management middle-ware on the same host as the UA or
> >>>service  management middle-ware devices doing the direct service
> >>>communication).
> >>>
> >>> If we want something like this then there is a bit of work to do to
> >>>define  the  DNS-SD/SSDP service types for Web Intent services and
> >>>how the UA will  emulate those services as Web Intents for use by web
> >>>apps.
> >>> Everything marked 'well-defined' in the above is negotiable but this
> >>>would  be  one method of hooking up devices to web applications via
> >>>Web Intents.
> >>>
> >>> Defining these necessary parts will warrant a separate spec on top
> >>>of the  Web Intents base specification. Perhaps we want to tackle
> >>>that in this group  as a separate activity?
> >>
> >> It could even happen in the DAP WG instead of the Web Intents TF, not
> >>that I  have any preference either  way.
> >
> >Where we could explore this further is a little unclear right now but
> >I'm open to suggestions and other proposals for device communication in
> >general.
> >
> >Thanks,
> >
> >Rich
> >
> >>
> >> - Cathy.
> >>
> >>> - Rich
> >>>
> >>>
> >>>> /g
> >>>>
> >>
> >
> >
> >--
> >Rich Tibbett
> >Opera Software ASA
> >
> >
> >