Hey,
maybe stupid question...
But will users use our connection manager for MSN ?
You are designing a very complex thing !
Why do you want to keep libmsn in a shell like to protect it ?
What I see for now is that you would like to use libmsn without Telepathy...
But well, who will use it without Telepathy ? Even aMSN2 will use Telepathy... 
(Do you think that aMSN will support a day libmsn ? Are you mad ? A total 
redesign of it would be necessary ) So if it is to do the job for some 
hypothetic people who will use it in a shitty product (don't forget that GPL 
doesn't forbid that) I would say it's useless... (By the way, shitty because 
it doesn't use new standards of interoperability)
You surely know that there is already a connection manager for MSN (still 
incomplete I agree) but if, finally, it works better and faster than ours 
(because it hasn't any layer to do some wrapping)... It's useless to make 
Roelof work on it and I am sure he has better things to do ;)...
Sorry to make you go down on Earth...
So for me Roelof should write the connection manager directly...
Phil

Le Sunday 16 July 2006 21:00, Harry Vennik a écrit :
> 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=12164
> > >2 _______________________________________________
> > > 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

Reply via email to