Okay, my first thought when reading Burgers' post was: Ooops, this seems to interfere quite much with the 'separate GUI and Protocol through events'-plans, but after some more reading, I have to admit this might be a good idea despite of that ;-)
But: using C++ is really a bad plan. I have never understood why people use a language that pretents to be Object-Oriented, but is cripple on all details of OO. If you want to go OO, use Smalltalk, Objective-C, Java, Tcl with [Incr Tcl], or something of equal quality. I do not know Telepathy, but from what I read in this thread, it could be nice. We should investigate on that. About the new project suggestion: DON'T DO THAT. We're talking about aMSN's future here!!! That other suggestion (a amsn2 module) sounds much better. After all, I was thinking of such already. Because what I proposed regarding protocol and GUI separation can hardly be done by changing code. It would be better to write new code, and copy/paste old code into it where it is useful. But we might decide now to use something other than Tcl for the protocol. After all, Tcl is a bit messy. But it is flexible too... Just like every language has its own advantages and disadvantages. Now about multi-protocol: did anyone think of its implications for the GUI? Having to deal with metacontacts is not very nice. Look at Kopete for example. It does what it should do, but it is far from userfriendly. And that seems to be caused largely by the metacontact support. I really won't like aMSN to suffer from that... So in fact, I should only want a multi-protocol aMSN if there would be a always only 1 protocol in use in an aMSN session. To use multiple protocols at once, you would need to have multiple instances of aMSN running then. Just like when you want to be logged in to several MSN accounts with current aMSN. (Or, maybe an even better approach: have tabs on the contact list window. One tab for each session running.) Burger, thanks for starting this brainstorm! aMSN is good enough to get even better! Op zondag 11 december 2005 21:25, schreef Youness Alaoui: > On Sun, 11 Dec 2005 15:00:32 -0500, Karol Krizka <[EMAIL PROTECTED]> wrote: > > On Sunday 11 December 2005 11:55, Le Philousophe - Phil wrote: > >> Very interesting !! > >> a communication system !! We won't have to write it !! But what is bad > >> with > >> libgaim for Telepathy ?? A D-BUS extension shouldn't be too hard to do ! > >> But if we want to rewrite all to made it saparated we should maybe > >> switch > >> to C++ or any other language not interpreted !! (Maybe Java ?? To steal > >> code from Mercury !! :p) It can bring better performances ! > > > > I say stick with TCL because then there aren't as many porting issues as > > if we > > were to use C++ for example. And it's waay faster than Java, after all > > everything is. > > two things, first, as I just said, we should go with C++ for the libmsn... > it's easier, ALOT easier, especially when we have binary with the MSNP2P > protocol... also, we can always make it portable with (for sockets for > example) "TCLSocket sock = Tcl_NewSocket(ipAddress, port)" ... we can use > the Tcl API and make the C++ code fully portable... > second thing is that Java is not that bad in speed, it's said to be as > fast as C/C++ and sometimes it's even faster... only requirment is to > enable JIT (Just-In-Time compilation, which means the bytecode is compiled > into native code when first loaded into memory, and then there's no > interpretation part)... > and from benchmarks, yes, on very big samples, java is faster in > processing than C (the reasons is the memory management).. problem is the > way the code is done in java when using GUI components.. code is SO > unoptimized most of the time... but still, GUIs are a bit slow, but that > should be fixed with ftureu releases of the JRE (sun developers > concentrate on optimization and speeding things instead of adding new > features)... > > >> But I think this system could be ideal since we could be standard with > >> all > >> other clients... Now the user will be able to have the aMsn core with a > >> Gtk > >> gui etc.... > > > > I think the "standard" part is the best about telepathy. For example > > every > > client won't have to make it's own extension for ecryption. > > > >> Anyway I think we must go on this project !! > >> Phil > >> > >> Le Sunday 11 December 2005 20:44, [EMAIL PROTECTED] a > >> > >> écrit : > >> > Hi guys, > >> > > >> > This will be a big email, and I hope it can generate a lot of > >> > >> talk. > >> > >> > This is a proposal for the future of aMSN that benefits several > >> > parties : aMSN, Telepathy and Farsight. Now you all know Farsight, and > >> > you all know aMSN. You might not have heard of Telepathy. It's a > >> > project funded by Nokia to developped a CORE for all IM protocols. > >> > >> It's > >> > >> > basically a spec and a system that will be the brain of all IM > >> > communications, including support for media (VOIP and video for > >> > example). It is also based on D-BUS. How it works is that you have > >> > connection managers for each protocol (basically a protocol plugin). > >> > And it would have a GUI on top of it. > >> > > >> > The thing is, we don't want to use Gaim's MSN protocol as a connection > >> > manager for telepathy. What we want is an aMSN based TCL connection > >> > manager. That would basically mean all the protocol code, plugged into > >> > telepathy through DBUS. Also, I would personally love a GUI on top of > >> > telepathy that is based on aMSN's GUI (because I am so used to it). > >> > > >> > So what would the result be? > >> > aMSN connection manager <-> Telepathy core <-> aMSN GUI > >> > > >> > Now, I know the GUI is being rewritten, would be very interesting to > >> > write it cleanly on top of the Telepathy core. It would also be very > >> > interesting to be able to separate completly the PROTOCOL code from > >> > >> the > >> > >> > rest of aMSNs organs. > >> > > >> > Whats in it for aMSN? Well, aMSN would then have support for any > >> > protocol that is supported by Telepathy. Very soon, the Jabber > >> > connexion manager for telepathy will be complete. Therefore at first > >> > >> it > >> > >> > would give aMSN Jabber support. Basically, aMSN would become a > >> > multi-protocol IM with an MSN GUI :) I know we talked about this alot, > >> > and I think telepathy is the solution. Also, aMSN would immediatly > >> > benifit from Farsight since the Telepathy core will have full support > >> > for Farsight. Obviously some of the current aMSN work would be lost > >> > (all the core stuff) but on the long term, it means that all the > >> > protocol work that has gone into aMSN will be used by any Telepathy > >> > application, and it will give it more exposure. > >> > > >> > Problems to solve : a TCL extension to give it DBUS support. Finally a > >> > good separation of Protocol/Core/GUI needs to be finished. Telepathy > >> > needs to work on support for Win32 (macosx already supported). I would > >> > like to note that the Adium people are already migrating to > >> > Telepathy and dumping libgaim. > >> > > >> > Please ask me any questions you guys have, and give me your feedback. > >> > >> I > >> > >> > would love for this vision to go forward but it will never be done if > >> > we don't have everyones approval of it. Also, I need to be alerted of > >> > anything important I missed. > >> > > >> > Links : > >> > Telepathy : http://telepathy.freedesktop.org/wiki/ #telepathy on > >> > Freenode > >> > Farsight : http://farsight.sf.net #farsight on Freenode > >> > > >> > Waiting for your replies, > >> > Laterz, > >> > Burger > >> > > >> > > >> > ------------------------------------------------------- > >> > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > >> > files for problems? Stop! Download the new AJAX search engine that > >> > makes searching your log files as easy as surfing the web. DOWNLOAD > >> > SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > >> > _______________________________________________ > >> > Amsn-devel mailing list > >> > Amsn-devel@lists.sourceforge.net > >> > https://lists.sourceforge.net/lists/listinfo/amsn-devel > >> > >> ------------------------------------------------------- > >> This SF.net email is sponsored by: Splunk Inc. Do you grep through log > >> files for problems? Stop! Download the new AJAX search engine that > >> makes > >> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > >> http://ads.osdn.com/?ad_idv37&alloc_id865&op=Click > >> _______________________________________________ > >> Amsn-devel mailing list > >> Amsn-devel@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/amsn-devel ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click _______________________________________________ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel
