[Telepathy] Welcome to our project page..

[Rob Taylor]

Stefan Eilers wrote:
> Hi Rob!
> 
> Am Montag, 1. Mai 2006 19:04 schrieben Sie:
> 
>>> Hmm, I do question why we need another project name and page -
> 
> Telepathy may not need another project name or page. The KDE implementation 
> into Telepathy need it. Of course, there are overlaping aspects but not 
> everything is related to telepathy.

I'd walk before you can run. There's a lot of basic 'Telepathy' work to
do for Qt before you go diving off into the (cooler) desktop-specific
side. We host python, glib, and C# work already, so why not start off
here and enjoy the synergy? There's a wealth of experience for you to
draw on, like any open source project.

>>> I'm quite 
>>> happy for all the KDE work to be done under the Telepathy banner, and
>>> using the same resources.
> 
> :)
> And the details about KDE and its implementation should not be mixed with 
> telepathy framework discussions. It should be seperated.. That's all.

Well, I would certainly say that at this point, its best to all work
together, there will still be a lot of experimentation to do.

As you can read here (http://guadec.org/node/242) we have already
implemented an entire platform integration with Telepathy, so by keeping
discussion all in one place you can benefit from our experience.


>>> But if you insist on having this KDE/rest of world split, then can we at
>>>  least put all the common stuff on telepathy.freedesktop.org? (e.g.
>>> state diagrams, mission control specs, etc.)
> 
> Yes. I would prefer it to put it on the official page and at least it has to 
> be there. The information which is published on our page is there, because I 
> wanted to be clear that this is not official and just for discussion 
> purposes.

The whole of the wiki is for discussion purposes. Fill up as you wish!
(This applies to everyone too). The core telepathy developers all keep
an eye on that wiki, any by working there you're unlikely to have any
misconceptions propagated for too long.

>>> Also, some more discussion would be appropriate - it seems to be all the
>>>  use cases and sequence chats are very wrong - and these are all cases
>>> that we've well analysed and have been implemented already.
> 
> Ok. Then, you should publish anything. We want to assist in extend telepathy, 
> but without detailed architectural information it is impossible to do so.

Hmm, This is an open source project. If you want detailed architectural
information, you'll have to write it - I'll happily offer sage advice,
but I don't have time to do this work.


>>> *In 
>>> particular* mission controls job is *NOT* to act as an intermediatary
>>> for all communication - this is madness -5 context switches to find out
>>> anything at all!! 
> 
> The communication itself should not routed via mission control. That is our 
> opinion, too.

Good.

>>> At the most basic level, all a mission control needs 
>>> to do is manage account details, launch connection managers, and handle
>>> incoming channel requests, launching the appropriate handlers based on
>>> platform/user choice.
> 
> Well, it is exactly what we wanted to show. But IMHO aren't things like 
> "handle incoming channel requests" and "launching the approriate handlers" 
> something which I would include into "intermediatary" jobs.. Is that wrong?

No, not at all. when a new channel appears, no one is assigned to handle
it - hence this is the job of mission control.

> What would you like to see, instead?

Exactly what I described above. I'm not sure what isn't clear.

>>> To be slightly more positive, If you guys can come talk a bit more,
> 
> Well.. The aim of our sequence charts is to point to the things which are not 
> clear/missing. This has to be the first step to discuss anything. Otherwise 
> we cannot communicate very well. 
> If everything is clear for you, as you stated, then you should help us and 
> give us some insight. 

The problem for me is that your diagrams are so wrong that it is a
useless point to start discussion from. I was under the impression you'd
be starting by drawing state diagrams for the current situation, and
then building on that. This still sounds the best way to go to me.

>>> getting some real sequence diagrams and state charts together that
>>> actually document reality would be very very useful to all concerned.
> 
> Our job is not to provide documentation about things you have written. We will 
> provide such sequence charts but the most important part is to provide 
> information how this architecture should work if it is ready. This has to be 
> discussed first. Then, we should analyse where we are and how to finish it.
> IMHO, you try to do it in the wrong order.

Where we are is: It Works. Download telepathy-gnome [1] or
telepathy-sharp[2], and try it out. Both these provide a basic 'mission
control' functionality. If you wish to understand the problem sphere and
current state of play, this is the best place to start.

>>> Right now I'm working on getting a nicer looking page up on fd.o, just
>>> waiting for moin 1.5 to get installed.. ;)
> 
> Great..
> I hope you don't fear that we want to provide another fork of thelepathy like 
> tapioka already is. 

I do indeed. Why start another project just to do the same work people
are already doing here, except in a different language? Sounds very
forky to me...

> But you may think about, how to help external people to 
> incorporate into this project. We don't have the time to make 
> reverse-engeneering, try to analyse how the missing parts should run and hear 
> that everything is wrong, afterwards. The job of mission control is 
> completeley undocumented, thus we wanted to put our fingers into this wound. 
> And I think, this worked quite well. ;)

I don't suggest you need to do any reverse engineering. I simply suggest
that you ask questions!!

We don't have time to produce much documentation ourselves atm, but we
do have time to answer questions, help point people in the right
direction, and we will of course take patches and give commit access to
anyone who's working on such things.

Most importantly, I must emphasise that dropping lots of data on us and
going 'tell us what's wrong' is *not* a useful way to start. Asking
questions is.

Thanks,
Rob Taylor

[1]http://telepathy.freedesktop.org/wiki/Cohoba
[2]http://telepathy.freedesktop.org/wiki/GnomeUI