Here is a suggestion of what I imagine the "core" Telepathy channel API
would look like (Channel.XPMNServiceProviderConnection). The
"higher-level" profile channel would use the functionality of this
channel to provide a simple API.
Is it reasonable that the signals use the exact data provided to the
methods (such as 's: Value' and 'xml: Value'), or should I let the
methods return an ID or something and track the reply using that?
A channel type for managing communication between two XPMN devices.
Due to the nature of XPMN, this channel can only be used with XMPP
connections.
While it is technically possible for XPMN application developers to
use this channel directly, application developers SHOULD implement a
higher-level and profile-specific channel instead (which internally
creates an instance of this class).
Rationale: Using this channel directly will force the application
developer to deal with low-level XMPP technicalities. Additionally,
a profile-specific middle-layer would allow an abstracted and usable
API.
You can use this channel to execute commands, get and set simple and
complex variables as well as subscribe and unsubscribe to events
(variable updates) on the service.
*Methods*
ExecuteCommand (xml: Command)
GetAllVariables (s: EventName)
GetLatestVariable (s: EventName)
SetSimpleVariable (s: EventName, s: Value)
SetComplexVariable (s: EventName, xml: Value)
Subscribe (s: EventName)
Unsubscribe (s: EventName)
*Signals*
Subscribed (s: EventName)
Unsubscribed (s: EventName)
CommandExecuted (xml: Command, xml: Result)
SimpleVariableReceived (s: EventName, s: Value)
ComplexVariableReceived (s: EventName, xml: Value)
SimpleVariableSet (s: EventName, s: Value)
ComplexVariableSet (s: EventName, xml: Value)
*Telepathy Properties*
auto_subscribe_features : <list of string> - read only
I appreciate any feedback, of course! :-)
Thanks!
Best,
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
[email protected]/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
[email protected]
http://lists.freedesktop.org/mailman/listinfo/telepathy
_______________________________________________
telepathy mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/telepathy
