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
2 _______________________________________________
Amsn-devel mailing list
