[Telepathy] telepathy-blue

[Raphaël Slinckx]

On Wed, 2006-09-13 at 00:48 +0300, Robert McQueen wrote:
> > 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.

That was how i started out by having a bt_address and bt_channel
required parameter for the connmgr so that he knows which device to
address. I switched to the scanning because i wasn't sure about how the
UI would have done to get the values. Since we agree that it doesn't
really matter for the UI to have specific bt support, then i guess it's
the best and obvious way to do it.

> 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.
> 

Great !
At the moment i use libbtctl for scanning and retreiving phone
capabilities. I could switch to gnome-bluetooth or that new HAL stuff
pretty easily anyway, so i guess i'll wait for hal stuff to be released
usable (never heard of the results of the SoC project)

> > 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!
> 

You're absolutely right, it doesn't make sense to use e-d-s in this
context. I think i'll just leave the client to do the magic to create
phone number handles, and not implement the phone contacts stuff right
now. Maybe one day, and if i see support is standardised. Or maybe
through libgnokii, but i don't like it that much, never worked for me.

> > * 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

Indeed. We already have this for account and password for example. In
this case the BT connmgr has completely specific fields that are not
account nor password.


> 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? :)
> 

Something worth doing indeed, for the hype factor, cause you still need
to grab your phone. But it's nice to receive a sms, then just hit a
'Reply with call' button, and pick up the phone and talk. Very hype


> 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... :)
> 

I need first to understand the whole gabble build system, because it's
hard to tell what's generated, from where, when, why, what's not, etc :)

Then i guess what'd be useful is something like we have for
telepathy-python, providing base classes for all the relevant objects,
with sometimes a generic implementation for the methods. Also i guess
all the .manager voodoo, with the extractor from the dbus method to
generate it, and all the ParamSpecFooBar i've seen in gabble. I guess
also all the debug stuff, the persist flag and all that kind of common
stuff could be pushed in that lib. If it's ok for gabble to depend on it
of course.

I'm going to read the build stuff and try to understand it :)

Raf