[Telepathy] Mission Control Spec

[Tobias Hunger]

On Thursday 02 November 2006 00:33, Raphaël Slinckx wrote:
> Good night !
>
> I sense excitement through my powerful telepathy skills. I also
> perceive it's because I just finished the Mission Control API Spec
> proposal !
>
> http://telepathy.freedesktop.org/wiki/Mission_Control

Hi Raf!

First I want to thank you for taking the time to write such a proposal. I do 
have a couple of issues with it though that I would like to address:

The first thing is that you do not mention Connection Manager/profile 
management at all. In my understanding that is one of the three central 
aspects of a mission control component (with the others being account 
management and componet startup). Will you still add such a part at some 
later time?


Account Management:

I found you mentioning profile management here and was a bit confused by that. 
Maybe you could work over the wording a bit to make it clearer how profile 
management relates to account management?

I further do not see the need of a changed flag. The GUI should be able to 
figure out which accounts it changed pretty well without the help of the 
account management.

The fixed string to identify an account is a nice idea, but I would prefer 
using a handle here: It is shorter, faster to compare and more consistent 
with the rest of telepathy. You already propose to have a "Name" (which I 
would personally change to "display-name" to make its purpose more clear) 
later on which can be set by the user. That is what most UIs will use to 
describe the account to the user, so I see no need for a human-readable ID,

I do not see why you need a enable/disabled state. In Houston all the accounts 
stored in the AccountManager are what you call enabled. An account 
configuration application can always back up the data from some accounts and 
store it someplace on the filesystem to simulate your proposed disabled 
state. In my opinion this is nothing a MC component needs to be concerned 
about. We should keep things as simple and flexible as possible.

Editing account settings is something you should not leave out of your API 
though! This is a pretty central aspect of the whole account management after 
all and has a great impact on being able to use account configuration 
applications from one MC on another.

I do not understand why you are trying to add contacts to accounts (maybe my 
understanding of that problem space is just lacking). I am trying to keep the 
concepts of contact and account as separate as possible in Decibel and am 
trying to push contact handling out of Houston itself. I have to admit that I 
am so far not sure whether this works out the way I hope it will;-) 


Synchronising personal data, presence and connection status across accounts:

Sorry, I do not think that is a good thing to enforce in a central policy 
daemon. I often want to stay online with one account and not with another or 
have a pseudonym on one account and my real name on an other, etc. I do not 
want that data to by in sync at all times.

I prefer having a interface to modify *one* account at a time in Decibel's 
Houston. A client application can then do the synchronisation business if the 
user wants that... much more flexible this way.


Requesting Channels:

This part is OK with me, but the chandler files seem much to coarse grained 
for my taste and to inflexible. Users will want to configure this, having to 
change around files in some system directory is nothing anyone will want to 
do.


Stuff outside of Raf's proposal:

Some part that is sadly not addressed by telepathy so far and would be really 
nice to have in a mission control component is an option to get a description 
of capabilities of a Connection Manager: This CM does support encryption (or 
does not), etc. Currently there is just no algorithmic way to find a good CM 
to try for a connection request: Basically the programmer has to know which 
capabilities a CM has. That is very unsatisfactory: It would be much nicer if 
the CMs would describe their capabilities, so that a mission control 
component can pick the "right" CM for a connection.

I know that this whether a encrypted connection is possible depends on more 
than just our CM, but it does not make sense to try for something that the CM 
at our end can not do. Why should I try CM X to eg. transfer a file to 
someone else if X can not transfer files? If CM Y can do so, then I should 
try that one so that I can report to the user "It is the servers fault" when 
the transfer is not possible;-)

How about adding a capabilities interface to the CMs?

I hope I was not destructive with my criticism. It is great that somebody is 
working on such an important add-on to telepathy! Please keep up your work.

Best Regards,
Tobias Hunger
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/telepathy/attachments/20061102/5a1c8127/attachment.pgp