Telepathy Status

Hey folks!

I will be leaving on Thursday for a two week holiday in England (if it
were in the U.S. I would say vacation :). I might check my mail once in
a while, but no hacking for sure.

Since I know you guys are clueless without me ;) I thought I should tell
you how things are going and a loose plan which I intend to follow when
I get back.

(Note. For the impatient, there are two big questions at the bottom)

In the last couple of weeks I have been trying to reach feature parity
between gossip/loudmouth and gossip/gabber, this is what works so far:

* Presence: Getting and setting presence + custom messages works.
* Messaging: Works. Robert McQueen suggested that text channels just
stay open as long as the conversation is active (ie. as long as the
window is open), since Gossip does not have those kinds of events yet, I
added a simple timeout. But on the user's end, it just works. It is
debatable if this is necessary.
* Roster management: Works. We could add and remove contacts, and we
could accept subscription requests.
* Aliasing: Works. You will need this patch[1] for libtelepathy for it
to work.

Doesn't work:

* Group chat: This is a largely different code-base in gossip than the
standard protocol stuff, so it will take a bit more effort, but should
be doable.
* vCards: Not implemented yet in gabble, once it is it will be very easy
to add.
* Avatars: Same deal. Easy once gabble has it.
* File transfer: Does this work in today's Gossip? Didn't look into this
yet.
* Resources: This is a jabber-specific thing, I think gabble does all of
the required magic for us. Besides giving the user the option to name
his resource, it shouldn't be part of anything else. IMHO, the fact that
it is used in libgossip and the UI is a negative thing anyway, because
that's not good protocol abstraction.

In the last couple of days I have stopped adding features and I have
focused on bug fixes and cleanup, which there is still _plenty_ of both
to do. Here are some examples:

* Memory management: it's still bleak, but for now at least I have no
glib warnings. Libtelepathy likes synthesizing signals when channel and
connection objects are disposed, trying to make that work for us, not
against us.
* Error management: Since we are relying a lot on RPC with an API that
is less than stable we have to fail gracefully. Using exotic connection
managers (like butterfly :) helps detect such shortcomings. Also thought
needs to be put in where we want warnings, or where debug messages are
enough.
* Spec conformance: Again, using different CMs helps find those blind
spots. Its easy to integrate gossip with gabble, its the other CMs that
will make stuff interesting. Messaging and presence already work with
butterfly, you will need this patch[2] for telepathy-python.

There is plenty of work in the protocols directory, I am deliberately
_not_ touching anything libgossip or UI related until the rumored merge.
Nonetheless things that could be done sooner rather than later...

Xavier's generic protocol widget is as ugly as sin, but beautiful
code :) rock on!
* We could take a few hints from the actual parameters flags to organize
it more logically, like all optional parameters should be in a
collapsible frame thingy, or in an "advanced settings" dialog.
* Some common strings like "account" could be replaced with proper
translatable strings with tool-tips and all.
* The "register" parameter flag could be used to determine the
sensitivity of the register button.
* We should figure out a way to reliably determine what protocol the CM
offers and just use a hard-coded widget, like the jabber one.
* Use protocol names to retrieve proper stock icons for different
protocols to be used in the GtkTreeModel.

Now some big discussion points, IMHO:
* Some time in the distant future we should do away with the
libgossip<->protocol abstraction. This will eliminate ugly exceptions we
have now, for example CM discovery at account creation time.
I still think there should be separation between libgossip and the
telepathy-related stuff, but the GossipProtocol interface might not be
the solution.
* We are right now building a vertical solution in the sense that we are
managing accounts, connections, contacts, and incoming channels all in
the same process. If we are truly subscribing to the telepathy way of
life we need to redefine the goals of gossip. Telepathy dictates that
there should be something called mission control[3] that will do all the
background handling of connections and account settings and delegate
actual communications to separate channel handlers, so these are some
options I see:
	1. separate gossip in to two processes, mission control, and everything
else.
	2. stay monolithic, and delegate unhandled channels to external
handlers.
	3. size down to a roster and IM interface.
	4. combination of 2 and 3, be a self sustaining process with an option
of cooperating with an MC.
Just thought I would throw that out there and hopefully flare up some
discussion :)

Whew! hope I didn't take up your whole day :)

[1] https://bugs.freedesktop.org/show_bug.cgi?id=8578
[2] https://bugs.freedesktop.org/show_bug.cgi?id=8577
[3] http://telepathy.freedesktop.org/wiki/Mission_Control%3A