Op zaterdag 15 juli 2006 12:28, schreef Roelof Kemp: > Harry Vennik schreef: > > Actually I thought libmsn would be the connection manager itself. Also I > > think that making it separate from Telepathy is likely to cause the > > connection manager + libmsn to be more complex, and thus slower than a > > protocol implementation thas is a Telepathy connection manager itself. > > Basically that is the reason why I suggested to make the Telepathy and > > MSN parts of the code call each other directly (and thus be a single > > unit). Doing it that way will make he MSN part depend on the Telepathy > > part, so no way it merges with your idea.... > > > > Roelof, what is your idea on this? Libmsn is a connection manager, or > > libmsn is just an msn protocol implementation that could be part of a > > connection manager? > > Well, I spoke with asabil (from the telepathy IRC), and he strongly > suggested to not make a connection manager but to make only a libmsn. I > also discussed it with Sander and the idea was that I should design the > API of a libmsn (version 13) which could be used by a connection > manager. Then, the connection manager would be as much independent as > possible from the lib. The lib, which should be more close to the MSNP > than to Telepathy should offer very generic functions. (the more it is > close to Telepathy, the less generic the lib is) I think design is > cleaner when the libmsn and the connection manager are separated, > because when a new protocol appears one has not to rewrite the > connection manager, but only has to create a new msnlib. > The way I see it is like this: libmsn should implement the msn protocol (i.e. use something existing) so that part is fixed. On the other side it should provide an API, which consists of a set of classes, methods, events, and maybe properties. Those can be defined in any way, as long as all commands and notifications in the protocol are somehow reflected. (All other possible constraints are optional, and are thus design choices to be made.)
In this case we decided to have amsn2 use Telepathy. Telepathy is a general API for communication, and is usable for all aspects of the msn protocol (although we might need to add a channel type, but I'm sure that won't be a problem if we cooperate with the Telepathy team to establish its API). So why won't we use this existing API? Please note that you can perfecty implement that API without caring a bit about D-BUS!!! Then in the end libmsn + a few xml files + dbus-glib bindings == connection manager for msnp13!!! To ease the implementation, you might have libmsn depend om libtelepathy by extending some classes it provides. Once every essential method has been implemented, libtelepathy may effectively drop out (in which case we could add a few #ifdefs in the header files of libmsn and a --without-telepathy build option). Using that build option will then change the class definitions such that they are not extending libtelepathy classes anymore, while still providing the same API. > However I see at least one (important) complication. If the lib is only > a generic lib and not a Telepathy Connection Manager, there must be some > way for notification upon arrival of msn messages. A generic lib doesn't > know about the IPC techniques (D-BUS for Telepathy) that are used by > higher level layers. So then my question about notification isn't still > answered. If the lib does know about D-BUS, then my question is > answered. (The lib should send a D-BUS message) glib signals will do the job both with and without D-BUS. (With the Glib bindings the IPC part can be implemented almost transparently.) > > In short: There is a design decision to be made about what is the > purpose of the msnlib. Should it be generic and should a connection > manager deal with the Telepathy and D-BUS stuff? Or should the msnlib be > integrated with a connection manager (and other Telepathy objects)? > > My idea is to create a generic lib if and only if the above complication > can be solved. > > I'll be away for this weekend, monday I'll be back ;-) > > Roelof > > > Op zaterdag 15 juli 2006 05:48, schreef Youness Alaoui: > >> I think what was meant is to have a LIBMSN, which would be completely > >> separate of telepathy (but still designed while thinking about > >> telepathy), THEN we'd have to create a simple telepathy connection > >> manager that will USE LIBMSN.. sort of a wrapper, but keep libmsn > >> separate from telepathy so non-telepathy clients can still use its API > >> if they want. > >> > >> KKRT > >> > >> On Sat, Jul 15, 2006 at 04:29:44AM +0200, Sander Hoentjen wrote: > >>> On Sat, 2006-07-15 at 02:26 +0200, Harry Vennik wrote: > >>>> Hi Roelof, > >>>> > >>>> Unfortunately however, you seem to have forgotten about Telepathy > >>>> somehow... Not only is the word 'Telepathy' nowhere in your document > >>>> except in the title, also there is not even a little similarity > >>>> between the interfaces specified by Telepathy, and those that you > >>>> propose. So, I'm sorry to say, but it won't work this way.... > >>> > >>> To be on the clear side: we discussed and we agreed that it will be a > >>> generic lib, staying close to telepathy where it makes sense, but if it > >>> doesn't, that is where the telepathy connection manager comes in. First > >>> the lib should be written, with some tests.c that will have unit tests. > >>> > >>> now i have to go, don't wanna miss my flight :P > >>> > >>> > >>> > >>> ----------------------------------------------------------------------- > >>>-- Using Tomcat but need to do more? Need to support web services, > >>> security? Get stuff done quickly with pre-integrated technology to make > >>> your job easier Download IBM WebSphere Application Server v.1.0.1 based > >>> on Apache Geronimo > >>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=12164 > >>>2 _______________________________________________ > >>> Amsn-devel mailing list > >>> [email protected] > >>> https://lists.sourceforge.net/lists/listinfo/amsn-devel > >> > >> ------------------------------------------------------------------------ > >>- Using Tomcat but need to do more? Need to support web services, > >> security? Get stuff done quickly with pre-integrated technology to make > >> your job easier Download IBM WebSphere Application Server v.1.0.1 based > >> on Apache Geronimo > >> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > >> _______________________________________________ > >> Amsn-devel mailing list > >> [email protected] > >> https://lists.sourceforge.net/lists/listinfo/amsn-devel > > > > ------------------------------------------------------------------------- > > Using Tomcat but need to do more? Need to support web services, security? > > Get stuff done quickly with pre-integrated technology to make your job > > easier Download IBM WebSphere Application Server v.1.0.1 based on Apache > > Geronimo > > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > > _______________________________________________ > > Amsn-devel mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/amsn-devel > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier Download IBM WebSphere Application Server v.1.0.1 based on Apache > Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Amsn-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/amsn-devel ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Amsn-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/amsn-devel
