[Telepathy] Telepathy and XPMN

[Jon Kristensen]

Hi again!

I just had a great discussion with Robot101 in #telepathy. We have 
concluded that I should not include this code into Gabble but instead 
make a channel plug-in and a channel manager. I don't yet know whether I 
should make one channel type like 
org.freedesktop.Telepathy.Channel.Type.XPMNServiceConnection (see my 
previous e-mail to the list for a suggestion on what this type could 
look like) and another channel for every service or just one big channel.

I'm leaning against the former, more modular, approach. The reason for 
this is that every XPMN profile is different, and using the generic XPMN 
service connection channel type to do the heavy communication lifting 
would mean re-using that code in every profile channel, which in turn 
would make profile channels much easier to write.

The profile channels' jobs would be to offer a profile-specific API, 
maintain a profile-specific state and use the channel type above to 
parse the string/XML replies into higher-level data-structures for the 
client, and (vice versa) the higher-level data-structures provided by 
the client into XMPP XML.

One client could for example say something like (using Java notation): 
remoteControlChannel.seek(5125) (where seek is a profile-specific 
method) and the channel type would then translate that into an XPMN/XMPP 
iq set event and send it to the device.

Perhaps I'm misunderstanding something here. Perhaps I should not be 
thinking about channel types as some kind of inheritance. What other 
approaches could accomplish the things mentioned above?

Thanks!

Jon Kristensen

On 01/03/2011 03:17 PM, Jon Kristensen wrote:
> Hello Telepathy people!
>
> I'm developing an XPMN media server called Pontarius. I'm currently 
> looking into how XPMN could be integrated with Telepathy. You can read 
> about Pontarius at http://www.pontarius.org/.
>
> First off, let me clarify some XPMN terms:
>
> *XPMN:* Stands for Extended Personal Media Network and is a 
> decentralized media network software architecture. It allows extended 
> media networks to communicate seamlessly and addresses service 
> discovery (allowing devices to find and identify each other and their 
> capabilities), security (access control, encryption) and extensibility 
> (making it easy to extend for future use cases), all while being easy 
> to set up and use. All-in-all, it's an extremely powerful way to 
> arrange your media networks.
>
> *Extended media network:* An overlay network consisting (XPMN) devices 
> from one or more networks, such as home networks. One problem that 
> XPMN solves is that devices are able to communicate (over for example 
> Internet) even though they belong to different subnetworks.
>
> *Service:* A specific task or set of tasks that devices may be capable 
> of fulfilling. One example could be a TV playback and recording service.
>
> *Device:* A logical entity in the extended media network. It does not 
> have to be a physical device; one physical device can contain multiple 
> (XPMN) devices. Devices are often bound to a specific action (such as 
> controlling media playback). A device may be a controller, a service 
> provider, or both.
>
> *Controller:* A device controlling one or more services. Controllers 
> can also be service providers. An example of a controller could be a 
> smartphone application that can act as a remote control for a media 
> player service, allowing the user to play/pause, change the volume, etc.
>
> *Service provider:* A device providing one or more services. Service 
> providers can also be controllers.
>
> *Profile:* A profile is an extension on top of the XPMN architecture. 
> It is a specification that describes a service and includes the 
> communication protocol used between controllers and service providers. 
> There can be many implementations of any given profile, and they 
> should be seamlessly inter-operable.
>
> A XPMN device is basically a connected XMPP account. A directory 
> service could be using the full Jabber ID 
> sprint3 at test.pontarius.org/pontarius-directory. XPMN devices 
> communicate by exchanging general IQ get/set/result messages as well 
> as a small subset of the pubsub spec (like subscriptions, events and 
> items requests). Service discovery capabilities also play a part. The 
> mechanics for this is the same for every profile. See The Status and 
> Variable Event Mechanism at http://www.pontarius.org/test/0-1-alpha-2/ 
> for a brief (and incomplete) example of what it could look like.
>
> Every XPMN profile has a specialized API for the job that it's doing, 
> and they all use the above mentioned methods to do their job. One 
> simple profile could talk to a media player service to do things like 
> start and stop playback (think remote control), while another profile 
> can negotiate and download some data over a Jingle and SOCKS5 
> connection from some kind of transfer service. The external API for 
> these profiles should be made as simple as possible, and the profile 
> should hide the "core" XPMN module (from the previous paragraph) from 
> the third party developer. He should probably only know about the 
> TpAccount he want to connect with, and the full JID of the service he 
> wants to talk to. He would most likely be developing a Telepathy client.
>
> I don't really know where the "core" XPMN code and the 
> profile-specific (remote control, data transfer) code should go, what 
> it should be (Telepathy channels?) and how they should communicate. 
> What role could Gabble sidecars play here?
>
> Any ideas, comments or suggestions would be very appreciated!
>
> You can read more in-depth details about XPMN in Dirk Meyer's thesis 
> at http://elib.suub.uni-bremen.de/diss/docs/00011878.pdf. Also feel 
> free to ask questions to this mailing-list or to me directly. :-)
>
> Thanks!
>
> Warm regards,
> Jon Kristensen
>
>
> _______________________________________________
> telepathy mailing list
> telepathy at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/telepathy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/telepathy/attachments/20110103/719b2ff5/attachment.html>