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