[Telepathy] telepathy-blue

[Robert McQueen]

Raphaël Slinckx wrote:
> 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.

As a follow up thought, the ideal would be that you had E-D-S with your
contacts in, fed into Galago, and the Telepathy feed for Galago adding
information about presence and capabilities. Then your client/whatever
can see a person with a phone number in Galago, and if you have a Tp SMS
backend, they will also have a text channel capability. It's then just a
case of if (entry.vcard_field == 'Phone' && entry.has_capability(TEXT))
then 'Send SMS' rather than 'Start chat'. Or whatever.

> 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

Yes, this is actually quite cool even from within your address book, if
you have LDAP to the company-wide directory or something. Note that it's
also theoretically possible in software to give your PC the bluetooth
capability of a headset, and hence receive/send the audio from your
phone via your PC's audio system... for whatever reason...? :P

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

Well, nothing in generate/ is used during the build except for the D-Bus
introspection XML in generate/xml-modified/ for making the -glue.h files
which the glib bindings use for exporting objects. In src/, we get the
-signals-marshal.[ch] files from glib-genmarshal being run on the
-signals-marshal.list files. The rest of the files in there are the rest
of the source code for Gabble. :)

If you want to know about the generate/ stuff... The
generate/xml-pristine/ stuff comes from do_xml.sh, which runs the
genxml.py from within telepathy-spec, and outputs XML files for the
combinations of interfaces specified in the gabble.def file. Then we
have a script that adds async annotations according to the list, giving
us generate/xml-modified/. The do_src.sh runs gengobject.py, which fills
up generate/src/ with auto-generated stub GObjects which implement all
of the interfaces as specified in the XML. When we add a new D-Bus
exported object in Gabble we generate this stuff and copy in the stub
objects to src/ as a basis; when we modify some Telepathy interfaces or
implement a new interface on an existing object, we do the generation
and then apply the diff (recently I started using wiggle to merge the
.rejs, it rocks!) to the real src/  None of this happens at build time
though, so you can ignore it. :)

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

Yeah, I need to take a look at where tapioca-glib is going. In some ways
I'm thinking the right thing to do is make sure nud's patch for
exporting GInterfaces on the bus is done, and having each Telepathy
D-Bus interface as a GInterface in the library, have base classes for
just ConnMgr, Connection and Channel, and have mixins for shared
functionality like group interface, properties interface, etc.
Pre-selecting which combinations of interfaces (streamed media = group +
mediasignalling, etc) the manager can use is not the right thing for the
library to do.

> Raf

Regards,
Rob

-- 
Robert McQueen
Director, Collabora Ltd.