Op woensdag 19 juli 2006 18:15, schreef Youness Alaoui: > On Wed, Jul 19, 2006 at 08:56:46AM +0200, Harry Vennik wrote: > > Op woensdag 19 juli 2006 06:43, schreef Youness Alaoui: > > > No way we drop ANY platform... not even in the beta phase, we want > > > windows beta testers too! > > > > That's right. That is why I said 'If D-BUS for Windows is ready BEFORE > > aMSN2 gets into Beta stage, there is no problem at all.' > > What I meant by 'in beta phase' is 'in svn'.. people use SVN, without > having us release an RC or a beta version, so if we want users to test > while we're developing, it should be working correctly from the very > beginning (what if WE want to work from a windows machine ?) > Why should anyone want? :-P (j/k)
If you understood the rest of my e-mail, you would have seen that I solved even that! Bit you apparently did not get it, So I'll just explain again. > > > For now I think it concludes our previous discussion in the other > > > thread about a libmsn vs. a CM for telepathy... > > > > libmsn is going to have an API in C that is similar to the one of > > libtelepathy. This will make the solution of the problem very easy. We > > can just have two ways of building libamsn2_tcl: > > 1. Link libamsn2_tcl against libtelepathy, and have libmsn linked with > > D-BUS bindings (thus being a Telepathy CM). > > 2. Link libamsn2_tcl against libmsn directly (calls to libtelepathy > > functions are changed to libmsn function calls simply by including one > > specialized header file that translates all names). > > first, libamsn2_tcl is TCL, so there is no compilation/linking.. secondly, > NO, I hate and I don't want any conditional code! I do not want any #ifdef > DBUS do this code, #else do this... #endif it puts the overall code in a > very difficult to read/unmaintainable state!!! Trust me, I saw this too > many times already! > No libamsn2_tcl is meant to be the library that provides bindings for TCL to all low-level components, while it is itself mostly written in C. And also I did not plan to sprinkle the code with #ifdefs, just one #ifndef HAVE_DBUS # include "libmsn/bypass_tp.h" # include "libmsn/msn.h" #else # include "telepathy.h" #endif or something like that. And that will probably be in a .h file. > > > in this case, we'll create a libmsn and we'll have it wrapped into Tcl > > > functions, we'll have a one application caling function APIs (Tcl stubs > > > calling the C libmsn functions)... and once and if telepathy gets to > > > the state where it is 100% multiplatform, THEN we'll reconsider it.. > > > > We can just use different build options depending of the platform. (That > > is, the one with Telepathy for Linux, and the one without Telepathy for > > Windows, and the Mac guys may choose which one they use for Mac). In fact > > we just jet the configure script set the build option based on > > availability of D-BUS. So people building aMSN on a Linux system without > > D-BUS would even get a working aMSN. > > see message above... > To it, I'll add something... > What are the advantages of using telepathy and dbus ? oh yeah, having more > than one protocol... but if I understood correctly, we're talking about > Dbus == IPC, INTERPROCESS communication.. which means BETWEEN different > processes.. does that mean that to launch amsn we'll say "hey, you first > need to launch the amsn 'server' (telpathy), then launch amsn client... ", > we're ONE application, why have many processes ? The background process in launched automatically when a msn connection manager is requested. This is handled completely by D-BUS. So no need for a user to start it. > also, this means that if you have one telepathy server runing, ANY client > could be launched and could receive the dbus messages and could connect.. so > you mean we could have more than one cleint running for the same account ? I > just don't get it... why use that ? why can't we have > intraprocesscommunication.. like doing a call to a function!!! we want > multiprotocol, then why isn't it simply a single API for communication ? why > can't we do calls from one function to another function, instead of sending > our call through a DBUS thing, then get our return value through a DBUS > thing again ? first, wouldn't that make aMSN SLOW as hell ? I'm not against > DBUS, on the contrary, I do want DBUS messages to be sent so that other > processes can be notified! like for example, you could create a custom > applet that would notify you when you get a message or whatever, BUT do WE > need to use DBUS internally ??? Sorry if I'm asking stupid questions, I > don't know much about telpathy and don't know much about dbus either, I do > NOT want to start a flame war, if it starts flaming or someone feels it > might start flaming, then we'll discuss it over IRC instead. I don't think it will get slow, because one such call over D-BUS will invoke a whole transaction most times. For example, when creating a chat: aMSN2 ---(dbus)---> libmsn "Start chat to [EMAIL PROTECTED]" * libmsn does everything to start the chat, and finally it has an SB connection ready for use. libmsn ---(dbus)---> aMSN2 "Here you got your channel: channel_text_1" (Of course this is very much abstracted!!!! but no more D-BUS communication is there that those two messages, while there is much more happening in background between libmsn and the MSN servers.) Also, aMSN2 just uses the same notifications that other processes can catch too, so we won't need to implement additional D-BUS notifications for anything. Btw: (IIRC) the messages from aMSN to libmsn are method calls, and thus are only received by libmsn, and nothing else, method return values are received only by aMSN. The signals (== event notifications) from libmsn to aMSN2 are signals, and thus broadcast messages that may be received by other processes too. Then the real gain of having the protocol implementation separated this way: it would be 100% non-blocking, and will thus avoid that the GUI does not respond at any time! Current aMSN has that problem because protocol code is running in the same thread. So D-BUS will really be useful, also to be used by aMSN itself. > All I'm saying is that burger said "hey, telepathy is cool" (he's > developing it) and we all said "cool, we'll use it", but did we really do a > study for this, did we really do an engineer's work seeing which is best, > which solution is better, why use this instead of this.. that should be > done... Here you're right. That's why we ran into the problem that D-BUS seems not to be supported on Windows, without us knowing that... So we're quite lucky that that can be fixed so easily by bypassing D-BUS (maybe with some threading layer to avoid blocking)... Btw, Roelof is now working on the design for libmsn that has an API like Telepathy, but still can be used without Telepathy itself. > for now, this discussion does not change any plan so far, we don't need to > know if we'll use telepathy/dbus or simply function calls, in order to > developer libmsn or the XUL thing or the Tcl core.. the glue between those > modules is in question here, but it's still far from now, so if anyone > becomes unsure, it is not a reason for you to stop doing what you're doing. > > KKRT > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Amsn-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/amsn-devel
