LOL, this is FUN!! We must have been typing our mails to get aMSN2 going at the same time! Anyways, we're moving now!
(Remember the time folks here said that aMSN2 was just an imagination, and would probably never exist in reality?) Op zondag 16 juli 2006 20:32, schreef Youness Alaoui: > Hi Harry, > Thank you for the explanation, indeed I didn't get it in the first > place.. and to be honest, I didn't understand in the second place either > > :P but I do get the general idea of what you're saying, unfortunately, I > don't know how telepathy and dbus works... + I just woke up and I can't > understand much at this time... > for this reason, I will quit the amsn team.... haha, no I'm just > kidding, I ment, I will quit this discussion, because it just makes me > feel more and more lost... but wait until I get my new PC, and I'll read > the docs and websites and I'll hopefully get back on track and be more > active on this subject. > >From what I understood of what you said below is to have the same API > for libmsn as telepathy's API... but I don't get it, why ??? you see, if > you're talking about having DBUS calls in libmsn, I say no, DBUS should > be in telepathy, and libmsn should NOT use that, libmsn should only have > API functions and callbacks... we should not force anyone using libmsn > to use DBUS calls... No, libmsn will not care about D-BUS. I was just talking about implementing the glib-equivalent of the API. Creating the connection manager will then just consist of adding the D-BUS bindings. > maybe I understood wrong too... > > btw, amsn2 project structure should be added to SVN and we should start > implementing the others modules because once MSNP13 will be finished, we > will need a client READY to use MSNP13, and not let libmsn hang > somewhere in SVN, unused for another year... At least create the amsn2 module. The rest of the structure can be done after a few weeks (max.), once the design discussions will show some obvious direction. At this moment it is just to unsure what to create in there. (Yes, I know, there was a layout done, but we don't know yet if it will fit our needs well enough.) > there is work to be done.. a lot of work to be done, and I hope everyone > will have enough motivation and time to do it!!! as an example, we need > to write the GUI modules (Harry, I think you're working on the xml2gui > module), we need the GUI xml files too, we need the 'data' modules, we > need the dbus for tcl module, we will also need to have a full listing > of everything we can do now to make sure amsn2 will not have less > features than amsn.. it's the only way people will switch from one to > another... etc... Not so fast... Our first aim is: being able to chat with aMSN2 using MSNP13. Additional features come after that ;-) Once aMSN2 implements most of the featureset of aMSN, we are ready for its first alpha release. > Can someone create the structure in SVN, Phil was about to do it but I > think he never did... once it's done, start commiting your code in > there... xml2gui in there (even if incomplete it has to be versionned!), > libmsn should be committed in there, so can someone add the new user to > svn access ? (Jerome/Alvaro?) There is no code yet that is actually going to be part of aMSN2, so nothing to commit yet. Let's say the first commits will be around 2 weeks from now. > > KaKaRoTo > > On Sun, Jul 16, 2006 at 12:36:47PM +0200, Harry Vennik wrote: > > Op zondag 16 juli 2006 07:08, schreef Youness Alaoui: > > > On Sat, Jul 15, 2006 at 06:30:06PM +0200, Harry Vennik wrote: > > > > 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... > > > > You apparently did not get the idea exactly, but also I was wrong. I > > forgot about a peculiarity of glib that makes the idea fail: overriding > > is not supported in glib, only something similar to what is called > > 'hiding' in .NET (although it is not literally hiding anything in glib). > > > > The idea was that, for example, a connection object from libmsn would be > > a specialized version of a telepathy connection object (i.e. it is an > > instance of a derived class). So invoking the NewChannel method would > > invoke msn_conn_new_channel instead of tp_conn_new_channel. > > > > This would work perfectly, because via D-BUS the call to > > tp_conn_new_channel on the client side would be translated to NewChannel > > by the client-side proxy, and the server-side proxy will translate that > > to msn_conn_new_channel, because on the server-side the actual type is > > known. (The terms client and server refer to D-BUS client and server, > > i.e. the IM program is the client, the connection object instance - which > > is in a different process - is the server). > > > > If you just bypass D-BUS, it won't work anymore, as the proxy is not > > there anymore! But of course, if the program using the lib is completely > > unaware of Telepathy, and calls the libmsn function directly, it will > > work again. > > > > Maybe the above does not seem a problem: it works in both cases that we > > intend to support. And that's right, so far the idea would work, but did > > you notice that in both cases where it works, libtelepathy is either not > > used at all, or only on the D-BUS client side? So the final conclusion > > is: we won't need libtelepathy in libmsn development! > > > > This however does not trash te core of the idea: libmsn API == > > libtelepathy API (except for the name prefixes being different: in > > libtelepathy it is 'Tp' for classes, 'TELEPATHY' for macros, 'tp_' for > > functions, in libmsn it would be 'Msn', 'MSN' and 'msn_' respectively.). > > > > Doing it this way will: > > - provide a perfect glib-style API for apps that just want to use libmsn, > > without Telepathy > > - allow us to create a Telepathy connection manager just by writing some > > xml files and a connection manager definition (the ini-style .manager > > file). - allow any IM application designed to use libmsn to be ported to > > Telepathy in a few hours! > > > > Harry > > > > > > ------------------------------------------------------------------------- > > 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
