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 Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel
