Le lundi 17 décembre 2007 à 17:25 +0200, Alberto Mardegan a écrit : > ext Xavier Claessens wrote: > > 3) RegisterChandler is on the AccountManager object because that's the > > object we are sure MC is always exporting when it's running. Chandlers > > can handle channels regardless of the account it comes from, so we can't > > put this method in Account interface. But I'm not sure registering a > > chandler is part of the account management... Maybe we should rename > > org.freedesktop.Telepathy.MissionControl.AccountManager to > > org.freedesktop.Telepathy.MissionControl, this object will be > > responsible of all operations on the MC itself. > > Maybe we can have it on a different object, that is > org.freedesktop.Telepathy.MissionControl.Dispatcher
Only for one method or do we have more to put in Dispatcher? I we go for a Dispatcher we'll have one object with AccountManager and Dispatcher interfaces, right? > > 4) If MC leaves or crash and gets restarted it will forget about all > > chandlers registered using RegisterChandler. That's a problem NMC has > > with filters too. Should MC save BusName and ObjectPath of all > > registered chandlers on file to restore if restarted, or should I impose > > in the spec a pattern for chandlers BusName and ObjectPath like that MC > > can find them using ListNames? > > If we go for the latter, then maybe we don't even need the > RegisterChandler function anymore, since MC would be also listening to > NameOwnerChanged. I'm not sure it's a useful feature but what I had in mind is to be able to register a Chandler without having it running. The chandler could install a .service file and another program could call RegisterChandler for it. and MC will start the chandler when calling GetInfo or HandleChannel. That gives me an idea: What if all chandlers need to be registered? When I start Empathy it registers empathy's chat/voip/etc chandlers. If kopette is started it will registers kopette's chandlers. That solves the problem of choosing the right chandler without the need of user configuration. With that solution .chandler files or used only to cache information, like that MC don't have to call GetInfo on each registered chandler. We can add a flag in chandler "StartEvenIfNotRegistered" for chandlers that does not depend on a particular client, in that case it's user's (or distribution's packager) responsibility to not install 2 conflicting chandlers. > > 5) How to choose between multiple IM programs? Imagine we have kopette > > and Empathy both installed and both having their chat chandler waiting > > for any Text channel. How MC will decide which UI to start? I think we > > need a file somewhere in $XDG_DATA_HOME that blacklist some chandlers to > > disable them. Like that we can build an application that shows all > > chandlers to the user and he can decide to disable kopette chandlers for > > example. That means we have to add some more information in .chandler > > files to give to the user translated name/description of the chandler. > > Maybe we could have an optional field in the .chandler files that lists > the environment variables that must be set for using this filter. For > instance, Empathy would be started only if GNOME_DESKTOP_SESSION_ID is set. > > Or there could be a field with the name of a file whose existence must > be verified prior to starting the CH. > This could actually make the RegisterChandler/GetInfo API useless (well, > in that case maybe instead of a file we could have a flag in the > .chandler file that means "use this CH only if its bus name is already > alive"). The more I think about it, the more I like the idea. :-) That's a possibility, yes. > > 6) We need translated name/description in presets files too. How do we > > translate for files? Using the same system than desktop files I suppose? > > I thought that .presets where only for specifying default CM parameters; > what name/description are you proposing? (...) > Mmmm... so you want the .presets files to contain UI-specific data, too? > In that case, I think the .presets files should have different sections, > one for the CM parameters, and one (or more) for the UIs. Since > different UIs might need different data (and icon size), there could > also be a different section for every different UI. > In any case, I think that MC should not even try to parse these data, right? The only big difference between presets and NMC's profiles in my draft is the ability to create an account without specifying a profile/presets. Clients/MC must be able to create an account using only information provided by the CM itself. For example if MyCompany provides a SIP service that needs some customised values I can put a .presets file in my webpage that the user have to save in ~/.local/something. The presets file will looks like: [Presets] Manager = sofiasip Protocol = sip Default-registar = registar.my-company.com [UI] IconBase64 = HGD12HGFD4HGFD1 --> MyCompany's logo, non-free data DisplayName[en] = "MyCompany's SIP service" Description[en] = "MyCompany provides a cheap service for calling any phone number for only $0.20 per minute" I'm not sure if UI section have to be parsed by MC to know what to return in GetDisplayName and GetIconName in Account interface or if those functions returns NULL and the client is responsible to look in presets for a default value. If we want base64 icon in presets Account's API will need one more function GetIconData() to be used by client if GetIconName returns an empty name. Xavier Claessens. _______________________________________________ Telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
