On Sat, Jul 15, 2006 at 06:30:06PM +0200, Harry Vennik wrote: > 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. >
I don't think libmsn should depend on libtelepathy, if you're talking about only for testing, then I say, no need to use telepathy for the tests, you can have a simple helloworld application do the tests for you.. I don't see why you would need to integrate libtelepathy inside libmsn... maybe you can be clearer and I'll agree... > > 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.) > yep, signals, or callbacks as Phil said, that's I think the simplest and more obvious solution.. the connection manager will register his callbacks to a function that generates the DBUS call.. it's that simple... I think glib handles this type of thing very easily.... > > > > 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 > > >>> Amsn-devel@lists.sourceforge.net > > >>> 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 > > >> Amsn-devel@lists.sourceforge.net > > >> 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 > > > Amsn-devel@lists.sourceforge.net > > > 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 > > Amsn-devel@lists.sourceforge.net > > 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 > Amsn-devel@lists.sourceforge.net > 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 Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel
