<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body text="#000000" bgcolor="#ffffff">
    Hello Telepathy people!<br>
    <br>
    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 <a class="moz-txt-link-freetext" href="http://www.pontarius.org/">http://www.pontarius.org/</a>.<br>
    <br>
    First off, let me clarify some XPMN terms:<br>
    <br>
    <b>XPMN:</b> 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.<br>
    <br>
    <b>Extended media network:</b> 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.<br>
    <br>
    <b>Service:</b> A specific task or set of tasks that devices may be
    capable of fulfilling. One example could be a TV playback and
    recording service.<br>
    <br>
    <b>Device:</b> 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.<br>
    <br>
    <b>Controller:</b> 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.<br>
    <br>
    <b>Service provider:</b> A device providing one or more services.
    Service providers can also be controllers.<br>
    <br>
    <b>Profile:</b> 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.<br>
    <br>
    A XPMN device is basically a connected XMPP account. A directory
    service could be using the full Jabber ID
    <a class="moz-txt-link-abbreviated" href="mailto:sprint3@test.pontarius.org/pontarius-directory">sprint3@test.pontarius.org/pontarius-directory</a>. 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 <a
      href="http://www.pontarius.org/test/0-1-alpha-2/">http://www.pontarius.org/test/0-1-alpha-2/</a>
    for a brief (and incomplete) example of what it could look like.<br>
    <br>
    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.<br>
    <br>
    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?<br>
    <br>
    Any ideas, comments or suggestions would be very appreciated!<br>
    <br>
    You can read more in-depth details about XPMN in Dirk Meyer's thesis
    at <a class="moz-txt-link-freetext" href="http://elib.suub.uni-bremen.de/diss/docs/00011878.pdf">http://elib.suub.uni-bremen.de/diss/docs/00011878.pdf</a>. Also feel
    free to ask questions to this mailing-list or to me directly. :-)<br>
    <br>
    Thanks!<br>
    <br>
    Warm regards,<br>
    Jon Kristensen<br>
  </body>
</html>