<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#ffffff">
    Hi again!<br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    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?<br>
    <br>
    Thanks!<br>
    <br>
    Jon Kristensen<br>
    <br>
    On 01/03/2011 03:17 PM, Jon Kristensen wrote:
    <blockquote cite="mid:4D21DA63.2010705@jonkristensen.com"
      type="cite">
      <meta http-equiv="content-type" content="text/html;
        charset=ISO-8859-1">
      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
        moz-do-not-send="true" 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
        moz-do-not-send="true" 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 moz-do-not-send="true"
        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 moz-do-not-send="true" 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>
      <pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
telepathy mailing list
<a class="moz-txt-link-abbreviated" href="mailto:telepathy@lists.freedesktop.org">telepathy@lists.freedesktop.org</a>
<a class="moz-txt-link-freetext" href="http://lists.freedesktop.org/mailman/listinfo/telepathy">http://lists.freedesktop.org/mailman/listinfo/telepathy</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>