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. _______________________________________________ Telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
