[Telepathy] Proposed standard MC API

[Xavier Claessens]

Le vendredi 10 août 2007 à 15:54 +0100, George Wright a écrit :
> http://projects.collabora.co.uk/~george/MissionControlSpec.html

Thanks a lot for your work!!!

Lots of little details, some questions, mostly about the consistence of
the API:

===== Account and AccountManager =======

1) AddAccount() with corresponding AccountCreated signal is not
consistent.

2) AccountDeleted signal is on the manager and Delete() method on the
account... Isn't it better to have both on the same object? I would vote
for the manager because the manager does the action of removing an
account, an account can't kill itself.

3) We have AccountStatusChanged signal on the manager but
GetConnectionStatus() on the Account, shouldn't be both on the same
object? Not sure if that should go to the Account or the Manager, having
on the account makes more sense but having on the Manager is easier to
be notified of status of all accounts at once... Maybe we can have
both...

4) AccountUpdated is emitted when I change an account parameter? If yes
same comment #3 (I change params on the account param but get notified
on the manager).

5) We can set the presence individually for each account, why should we
have a group in the API? Clients wanting that feature can manage groups
themself and set the presence on each account... But that's easier like
that maybe... not sure about that.

6) Missing GroupsChanged signal... On Account or Manager (same has #3
and #4)?

7) Maybe we should have a convention for signal naming: FooChanged or
FooUpdated?

8) Maybe we should rename SetPresence() to RequestPresence() to be
consistent with the GetRequestedPresence() naming?

9) Maybe we should split PresenceChanged signal to
RequestedPresenceChanged and CurrentPresenceChanged?

====== ProtocolManager =====

10) ConnectionManagers() => usually we use the GetFoo naming, it should
be GetConnectionManagers() or ListConnectionManagers since it's the same
kind of thing than ListAccounts. Same for other methods on that object.

11) Is ProtocolManager needed at all? I think it should be replaced by
the profile system.

==== ChannelHandlerManager ===

12) Can't we use the ChandlerManager name?

13) for the file format, what about adding a HandleType field?

14) Maybe the spec should tell about default search paths, like <all xdg
dirs>/share/mission-control/

15) SearchPath() should be GetSearchPath()

16) Maybe we should remove Scan() and let MC do that directly in the
SetSearchPath() method?

17) ListChannelHandlers() is useless, there is nothing in the
ChannelHandler API that can be used by clients.

18) I think priorities should be set in the chandler file format. How
can a client decide the priority of other clients? For example the
logger program could change the priority of the chat UI handler, seems
not good.

19) In the end ChannelHandlerManager is only useful to set/get
SearchPath... Is that important at all? I think simply define that MC
should look in xdg dirs is enough.

====== ChannelHandler ======

20) I think Accept signal is useless. If an handler rejects a channel it
can just call Close() on the channel. If an handler wants to give the
channel to lower priority handlers it can call Continue. If an handler
don't want lower priority channels to handle that channel it just does
nothing and Close() the channel once the job is done.

Otherwise I think it's OK :D

Xavier Claessens.