On Sunday 22 October 2006 10:43, Michaël Larouche wrote: > I have some thoughts messing up in my head about Telepathy adoption. This > maybe look weird from the guy who volunteer to do the testbed Telepathy > plugin but these points need to be taken into account. > > - Mapping configuration GUI to connection manager key/value configuration > > This is my short term concern about Telepathy adoption. Each connection > manager has different key/value for a defined protocol. We can't show a raw > key/value UI to the user, like the current basic UI in Telepathy plugin. So > we need a set of UI configuration template for each protocol. How we will > manage those templates ? In plugins ? As a fallback for an unknown > protocol and/or connection manager, we will use the basic key/value UI > until someone made a UI for it. > > Maybe we should considerate creating those UI using Kross and/or KJSEmbed > for easy deployment, update and creation, and require no compiling :) >
I'm not sure I understand the concern here. What do you mean when you say "Each connection manager has different key/value for a defined protocol"? Why do we need templates? > - Creating a list of "certified" connection managers tested and reliable > with Kopete > > We should create a list of certified and tested connections manager that > ensure that work well with Kopete. Like integrate well into Kopete UI, > support most features of X protocol. I'm pretty sure many advance users > will complain about X protocol not working because of that connection > manager. > > In short, going the Telepathy way will maybe make the user support more > complicated because we have more variable configurations. So if we have a > list of supported connection managers, we could tell the user "Hey use a > supported connection manager !" ;) > Who's going to maintain that? > - Respect of KDE settings (Proxy, Phonon, Address Book, etc...) > > They are some bug report about some protocol plugin that doesn't respect > the KDE proxy settings. How do we ensure those settings are respected using > Telepathy. > That's a good question. Hopefully it's as simple as saying, "hey you! connection manager! Here's the proxy I want you do use to connect to. And here's the audio devices that I want to use" or something along those lines. > Also for the voice and video, we will need to tell the connection manager > to use those devices and settings from Phonon configuration. > > - Specific interface for type of protocols, to not loose specific > functionality of each protocol (disco search in Jabber) > > This is about regression of features. The main point of Kopete is to > integrate many protocols into a consistent interface but without loosing > the native features of protocols. This is one reason I started using > Kopete(or any similar program) because I wanted multiple native support for > each protocol, which is not the case in Jabber Transport. I was tired to > switch to a native MSN client just to transfer file. I'm thinking about > Service discovery in Jabber. Robert McQueen talked about maybe doing > interface for specific protocols in Telepathy specification. > > - What about the UI in protocol plugin ? > > What we shall do about the UI in protocol plugin ? We can't use them > anymore since the implementation is separated by D-BUS. I don't understand this question either. AFAIK, connection managers don't have UIs, so it's up to us to provide a UI to the user for a certain family of connection managers, say MSN connection managers, for example. There should be a list of standard settings that should be configurable. IMHO, we seem to be one of the bigger early adopters of this technology, so we should do what we can do make it work for us in a general enough way that everybody else who uses it doesn't have to go through the same pain it appears we will. -- Matt _______________________________________________ kopete-devel mailing list kopete-devel@kde.org https://mail.kde.org/mailman/listinfo/kopete-devel
