Re: intents broker == user agent ?

On the subject of if it should be a SOAP or JSON object you send is
there any difference?  I only say because SOAP messages are just a
series of strings in its basic form.  So as long as you agree that you
are sending SOAP messages then the strings are just JS strings so are
part of the structured clone algorithm and could be managed by the
postMessage on the port.

Now if you want to deal with SOAP as object constructs then that would
be down to a library that serializes and deserializes the message.  At
a high level I believe this can still be managed by the lightweight
action/datatype pair in the intent definition, the datatype being the
indicator to the protocol being used.

Having said all that, I am just assuming you know the protocol that
you are talking and not the case where I say I want to share a link
and the tv is the receiver.   In this case the client app would just
send a link to the UA via startActivity and the adapter in the UA
would have to know how to communicate with the user selected service,
which would be the TV in this case.  That hardware bridge, is out of
knowledge area.



On Fri, Nov 25, 2011 at 8:14 AM, Giuseppe Pascale <giuseppep@opera.com> wrote:
> On Wed, 23 Nov 2011 19:48:38 +0100, timeless <timeless@gmail.com> wrote:
>
>> On Wed, Nov 23, 2011 at 12:41 PM, Giuseppe Pascale <giuseppep@opera.com>
>> wrote:
>>>
>>> JC, all
>>> as I understand it, Web Intents is just a framework that allow
>>> application
>>> to "discover" other application via the mediation of the UA.
>>
>> discover and communicate.
>>
> correct
>
>>
>>> Furthermore, even if intents provide a way to discover a service,
>>> we also
>>> need to address the communication part to fully cover the requirements
>>> around communication with home network services.
>>
>> There's a difference between ensuring that there's a way to
>> communicate (which should be covered here), and ensuring a requirement
>> for a specific transport.
>>
> agree, but this is one of the important parts.
> Once you have discovered your service, you need to know which "protocol"
> to speak in order to interact with the service. Keeping in mind that a
> service may not be a web application and may not be running on the same
> device (at least in our scenario)
>
> Being able to postMessages is fine, but I need to know the format of these
> messages. And in the case of UPnP (just to make one example) this format
> is already standard. The only missing piece from the puzzle is how do I
> send UPnP messages? Do I define a JSON mapping that is actually translated
> into SOAP messages from the UA, or can I get an opaque identifier (in
> order to preserve privacy) and use XHR to send messages to this?
>
> BTW you can see how this could work via XHR with this Opera extension
> https://addons.opera.com/en/addons/extensions/details/teletube/0.9.3/
>
> The question is also (as asked by Dave and others in other threads),
> should the communication be limited to postMessage or would be possible to
> extend it to other messaging paradigms already available (e.g. xhr,
> websockets)
>
>>> This last part needs to be done somewhere else (in DAP).
>>
>> It doesn't necessarily have to be DAP. It might be that you will just
>> end up with someone who writes UPnP<->Intents gatewaying code and
>> delivers it. You might deliver it to OS vendors (Microsoft, Google,
>> Apple), or you might deliver it to Device vendors (HP, Dell, Lenovo,
>> IBM), or you might deliver it through Markets (Addons.mozilla.org, App
>> World, Apple's Store, Google's Store, Amazon's Store), or you might
>> include it on e.g. CDs (or USB sticks or via a link from a QR code)
>> which you ship with your UPnP Devices.
>
> sure, I meant dap for those parts that makes sense to discuss there.
>
>
> --
> Giuseppe Pascale
> TV & Connected Devices
> Opera Software
>
>



-- 
Paul Kinlan
Developer Advocate @ Google for Chrome and HTML5
G+: http://plus.ly/paul.kinlan
t: +447730517944
tw: @Paul_Kinlan
LinkedIn: http://uk.linkedin.com/in/paulkinlan
Blog: http://paul.kinlan.me
Skype: paul.kinlan

Received on Friday, 25 November 2011 11:42:29 UTC