[Telepathy] telepathy-blue

[Robert McQueen]

Raphaël Slinckx wrote:
> Hi !
> 
> I started working for fun on a bluetooth/sms connection manager.
...
> Supported are sending of sms through telepathy interfaces. I also have
> everything setup for receiving SMS but the sms decoding code isn't ready
> yet.

Cool!

> I need to address some issues, like how to map TP specs to that kind of
> manager.
> 
> For the moment:
> * Connect = Scan all BT devices pick the first one that has rfcomm
> channel and connect to it.

This sounds bizzare. It should at the very least be necessary for a UI
somewhere to present you with a choice of phones, and it be necessary to
specify which phone you want when you create a connection object. You
should check out Matthew Garrett's Summer of Code work for discovering
and using Bluetooth devices via HAL. Sending a HAL device path (or some
more persistent ID? not sure) to the RequestConnection argument would
probably be reasonable, then the config UI for this can use the HAL
methods to enumerate BT phones, and the backend use the HAL actions to
set up rfcomm devices for us.

> * RequestHandle = request a phone number (intl format only ATM)
> * RequestChannel (text).Send = send sms to the BT phone to the number
> represented by the channel's handle.
> * RequestChannel(text).Received = a SMS is received by the phone from
> the number represented by the handle.

This is all fine.

> What could be possible is:
> * hook in evolution-data-server in some ways to get phone numbers and
> create the contact list channel. Or maybe read the contacts from the
> phone (that would require writing support for it, and coming dangerously
> close to libgnokii, i bet most phones implement their own contact
> retreival protocol, i don't want to do that)

Hmmm... no. The contact list channels are supposed to be a wrapper
around data stored server-side, and a way of managing it, not a proxy to
your address book in any circumstances. If the SMS backend ever
manifests any contact list channels (and there's no compelling reason
that you must - clients should be able to deal with this), they would
come from the phone's address book. If you wish to have an address book
with your phone numbers in, and dispatch Telepathy actions, fix this by
making your address book program call Telepathy, not by making Telepathy
into your address book!

> * Use the yet-to-be-created telepathy 'Group' interface (to present
> stuff like jabber server-side contact groups, or other). Map each BT
> device to a group, and then present contacts for each bt device in those
> groups. Makes sense only if using contacts from the phone then.

There's no new interface required really; they will be represented as
ContactList channels with the yet-to-be-created GROUP handle type. This
wouldn't be the right way to handle multiple phones; merely to represent
contact groupings on a single phone.

> * Maybe the connmgr could accept as parameter the BT address of one
> device (used like a jabber ID), then the UI would have to be BT-aware
> and perform the device selection (and retreive the device address to
> pass to the connmgr)

Yeah; I'm pretty much resigned to the fact that it's not quite possible
to automatically generate sensible UIs based on arbitrary fields
required by certain connection managers. The best we can do is try and
standardise where possible and admit that configuration UIs will
probably need some manager-specif code. It's the same reason
jabber:x:form totally sucks - it places prescriptions on what the UI
should look like and how it should behave, which might be totally
unapplicable on your phone/PDA/laptop/screen reader/braille display/toaster.

> I think the long term goal is to be able using galago or whatever to
> detect that a contact (from e-d-s or jabber or any other medium) has a
> e-d-s phone number, then add a menu item for that contact 'Send SMS'
> which would trigger a request on the sms connmgr.
 >
> Is this acceptable for an UI to special case these kind of things ? I
> guess yes since the UI is the final end-user product and has to contain
> such special cases to allow a nice user-experience.

Yes, the address book application is allowed to represent things as it
sees fit, or provide a shortcut to do something, etc. What's important
is that you don't try to make things conform to parts of the Telepathy
API where they don't fit, because it will cause big problems in the long
run when non special-cased clients meet your backend - if there's no
roster on the server, have no contact list channels, if there's no
presence, have no presence interface. Don't try and invent the data or
read it from somewhere else or poll, because the Telepathy abstraction
is supposed to present what's actually available.

Note that on a related note: you *can* validly hook up the StreamedMedia
channel interface and have it dial calls for you on your phone, and
represent incoming calls as Telepathy channels, because the media
signalling for streaming has been split off to MediaSignalling interface
which you would obviously not need to implement. Cool huh? :)

> Thoughts, comments, anything ?

Good stuff. I remember on IRC you mentioned you couldn't be bothered to
copy bits of Gabble and modify it... I'd love to see some work on trying
to work out which are the common bits, maybe move stuff over to
GInterfaces or base classes as possible, and spin out a libgtpcm (glib
telepathy connmgr) or something more catchy... :)

> Testing and bug reports are appreciated of course. Maybe we want this to
> be hosted on telepathy repositories ?

Sure thing, if you mean projects.collabora.co.uk we can sort this out on
IRC, or if you want something on telepathy.fd.o we can add you an
account on fd.o - file a request according to
http://www.freedesktop.org/wiki/AccountRequests.

> Enjoy,
> Raf

Regards,
Rob

-- 
Robert McQueen
Director, Collabora Ltd.