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.
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) 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=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
