Re: Home Network Service Discovery and Web Intents

[removing unneeded parts to make this mail more readable]

>>> Giuseppe Pascale
>> Claes Nilsson
> Paul Kinlan

>> A general conclusion from the discussions on this mailing list seems to  
>> be that Web Intents is a pure discovery and service selection
>> mechanism only. So, when discovery and user service selection is done
>> any further needed communication between the Client web application and
>> the Service web application is done by some other "persistent" channel
>> than the Web Intents "payload channel".
>>However, the discussions are much about the abstraction level for
>> this other "persistent" channel.
>>> Not only the abstraction level but also the actual tool to use.
>>> I think that for some levels of abstraction there are still multiple
>>> ways of achieving the same result (e.g. send soap messages via XHR Vs
>>> via postMessage).
>>
>> Yes, I agree


Paul, may I ask you an opinion on this? I think the current design of web  
intents is based around postMessage and do not allow for any other  
messaging mechanism to be used.
Is that correct? Do you think this could be changed and could bring  
benefits?


>>> 1. I agree that using an "high level protocol" is an option and is
>>> exactly what I meant in option 1 with "//communicate with the HN
>>> device" (I assumed the message channel could also be retrieved as
>>> argument of the callback). In my case though I was proposing to have
>>> high level protocols for each verb (i.e. for each common use case) and
>>> fallback on your approach only for less common use cases.
>>>
> The callback should generally return the same type of data that it
> sends to the application, so for instance if you edit an image if you
> get a callback it should be an image.

Is this true for all verbs? I see why you want to do this for "edit" but  
what about "share"?

I would expect in return an object that I can use to extract some info,  
e.g. if the "share" action was successful or not.
If I get a "response" object, I could also use it for other things.
For example I could start by "View"ing my video, but from the intent  
response I get to know the selected service is actually a UpnP device and  
I get a pointer I can use to talk to the device using UPnP
e.g. via XHR.

(maybe there are other ways to convey this info. if so could you point  
them out, and maybe document it somewhere if not already done?)


> On another note, the execution
> of the callback in startActivity, essentially means the users has
> completed their task, so a message channel in the case wouldn't
> help.....

I would expect to know at least if the action was successfully executed.  
Or is there another way to achieve this?



>>> 4. I'm not sure if we are proposing the same thing or not: do you
>>> imagine this "mytvprotocol" to be a wrapper around one specific
>>> protocol (say UPnP) just using json, or would you expect to be a
>>> generic protocol that can be mapped on different protocols? If the
>>> second, how do you think you can support the inevitable differences
>>> between network protocols (in terms of supported functionalities?)
>>> Would you expect the have "extensions" to the basic protocol for
>>> additional functionalities?
>>>
> I would say you use the type encoding to informally agree on the
> protocol being used to talk with the device and then use that to send
> message across.  The theory is that if the developer of the client app
> specifies some esoteric API then they know they are doing this as an
> explicit choice and can therefore form their messages correctly.  If
> not, the remote device or app should ignore the messages.
>
> This should in theory cover the aplication/* data type where I as a
> client app developer say that I want to find all services that support
> anything under application - this means they could find a TV and start
> sending the wrong messages to it, which the TV should drop and close
> the connection.

The problem is not with esoteric API. That is well covered by the paradigm  
you propose and I agree.
What I'm concerned instead is with very common use cases that can  
(nowadays) already be implemented using different protocols.

Let's once again look at the push play use case
http://www.w3.org/wiki/WebIntents/Home_Discovery_and_Web_Intents#Use_case:_push_play

If all I want to do with my app is to watch a video on another device in  
the home, I don't know which protocols devices in the home support and  
also which protocols the user-selected device supports. Assuming the  
application is able to "talk" all different protocols, it still wants to  
start asking for something more generic, than refine the communication.  
That is why I was suggesting you could start with "View" than in the  
response get more info on the particular protocol the selected device is  
able to talk. After that you can use another intent or another mechanisms  
(e.g. XHR) to communicate with such device.

Note that I'm not generally concerned about your proposal, that is  
actually similar (from this point of view) to Opera/CL proposal on  
discovery [1]. What concerns me is that with intents you have generic  
verbs that will be used, so this could create confusion or duplication of  
code. So if we decide to go for generic verbs, I think allowing to hook  
into the reply a way to know which protocol the device can talk is  
valuable.
This doesn't need to be a message channel though. It could be just a  
"standardized" way to define these extra info that the application can  
handle accordingly.



>> I interpret the main idea with Web Intents so that a Client application  
>> issuing an Intent should not have to know anything about the low level  
>> service discovery and communication details of the Service selected by  
>> the user. So the protocol run on the messaging channel should basically  
>> be generic. If I understand you correctly Paul, you are proposing an  
>> additional and optional possibility for Clients to use protocols  
>> tailored to specific devices? Is this correct?
>
> I am saying that the protocol being used to transport data to the
> devices should be the same that is specified in the data type
> attribute.  If "application/tv+something" is an set of XML messages
> then they are just XML Messages sent over the message channel.  If it
> is binary data, then they are Blobs sent over the message channel.
>
> This message channel is just a generic channel, the protocol on the
> channel can be very specific, it is expected that applications either
> side of the conversation know and understand the protocols being used.
>

my concern on this is (as described above) that in many cases I know the  
"type" of protocol I should use only after the user select which service  
to use.
So I start with "View" this video (so type=video) than I get a response  
 from a service saying "I'm playing it, and btw I can also talk UPnP".

The alternative is to define a generic "application/tv+something"  
protocols and let that be a wrapper for all home networking protocols. But  
with this approach we define a difference between a home network service  
and web services, and also an overlap with "default" verbs. That is  
something I would like to avoid.



[1] http://people.opera.com/richt/release/specs/discovery/Overview.html


-- 
Giuseppe Pascale
TV & Connected Devices
Opera Software

Received on Monday, 12 December 2011 15:58:08 UTC