[jdev] Re: Local proxy for multiple applications

[Robert McQueen]

Michal Vaner (Vorner) wrote:
> Dne pátek 21 duben 2006 19:49 Magnus Henoch napsal(a):
>> I haven't looked at it myself but Telepathy might be a place to start:
>> http://telepathy.freedesktop.org/wiki/

I was about to make a pointer to our project. I'm one of the lead
developers on the Telepathy project, and although slightly off-topic for
this list, I thought I'd at least answer this seemingly unfaor appraisal
of our efforts to date.

> Why do simple things in complicated way?

Because it's not a simple thing. If you want to create a protocol which
can act as proxy for any arbitrary real-time communication protocol you
care to name, trying expose less complexity to client authors who don't
care about the perculiar features of a given protocol, but not
restricting the extensibility of those who do, it's absolutely not a
trivial problem.

It's similar in form to the problem which XMPP itself aims to solve
(making a protocol which is extensible enough to gateway on to other
protocols and extend with new features), and you can hardly say the
overall result of that is simple, but we've decided to use D-Bus as our
basic transport because it has bindings to most popular object systems
(glib, qt, python, perl, c#...) that make coding against it pretty easy
to get going.

If you want something which *is* simple, and discards all of the
features of different networks, perhaps Bitlbee would be what you
wanted. Everything then becomes just an IRC network where you can only
send/receive plain text, but it's just not what the goal of the
Telepathy project is.

> And why the hell not separate different things as much as possible?

We are all in favour of this. Our goal is that protocol code is
seperated into backend D-Bus services. Front-end clients which implement
particular functionality like managing your contacts, text chats, voice
calls, file transfers, etc, interact with different objects provided by
these backend services. Different communication types are split out into
different objects - we have a Connection object which represents your
server connection, from which you can request or be given Channels to
perform communications over, of the various types I've mentioned.

> Why not use sime pipe or network socket directly?

Because then client authors would have to write their own
marshalling/demarshalling code. That's about all libdbus does, and a
daemon to route messages based on what people have said they do and
don't want to receive.

> I wanted to provide just a proxy, that would be able to filter the 
> stanzas out, send them to server and allow some more control using some other 
> XML. But not move all the ways of comunication to some daemon and not be able 
> to send custom data that are not supported by the procedure of RPC for sure?

What on earth are you talking about? D-Bus has a completely recursive
arbitrary type system. You can send arbitrary structures, arrays, maps,
primitive types or any combination of those in any method call, reply,
signal or error. So you can send strings, integers, byte arrays, hash
tables of strings to arbitrary types, whatever. There is no limitation
in the type system I've run into so far, it's pretty elegant.

> Why does all the freedesktop projects seem to me as an attempt to make linux 
> as bad as windows? :-(

Ignoring this.

> Sorry if I may seem as an extremist here, but this seems to me as a bad thing. 
> This would disallow the extensibility of the protocol, if used.

Nonsense. Telepathy is created from the ground up to allow extra types
of communication channel to be added, extra interfaces added to existing
channel or connection objects. Our XMPP backend is our main focus at the
moment, and it's a very good chance to show how we can expose the power
and flexibility of the XMPP protocol within the Telepathy interface,
splitting out different tasks like file transfer, audio calls, MUC
chats, etc, into the respective channel types within our specification.

As I've just posted to our (admittedly rather quiet) mailing list, we
think it's going reasonably well at the moment:
 http://lists.freedesktop.org/archives/telepathy/2006-April/000026.html

We're aware of three frontend projects currently on the go, and nobody
has come back to us to say the concept is entirely broken and our
approach overcomplicated. It's still possible to write something like 10
lines of Python and send messages to someone, but by adding more
functionality you can take part in a Jabber MUC and manage the room
members and settings, place voice calls, manage your roster, etc.

We're definitely receptive to feedback about how our approach can be
improved, and would love to discuss how we can make Telepathy serve your
needs better. It is, after all, intended as a standardisation effort.

Regards,
Rob