Hi Harry, First thanks for the taking the time to answer me. Overall, I think it should be discussed over IRC, I HOPE to get my new PC by Friday (damn stupid bastards of assholes of whatever being late in ordering my new PC parts...) Anyways, i'll comment (briefly for once) on what you said, until we get this all straightened out over IRC or msn..
On Wed, Jul 19, 2006 at 09:49:37PM +0200, Harry Vennik wrote: > 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) > BECAUSE!!!:@ :p j/k too > 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. > Yes, ok, but I didn't think we'd go by developing a two version of the code because i thought we'd need ifdefs everywhere... so forget it. > > > > 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. > humm.. i don't know why you say that.. do we need any C->Tcl calls ? I think only Tcl->C calls since Tcl will be the core, no ? Tcl will call the dbus thing ? dbus extension will be generic and won't need to interact with libmsn if compiled differently... calling C from Tcl is easy, but Tcl from C is even more easy (Tcl_Eval()) > 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. > > I see what you mean now, and thank god it's not about developing two versions in hundreds of ifdefs... but i don't think it will be that simple.. maybe it will, but I simply don't think so. you see, if there is NO difference between telepathy and libmsn in the API definitions, then I don't understand what is the CM doing there, why libmsn uses this API and why we'd need to depend on telepathy... > > > > 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. > Yes, of course, I thought about that, but why 2 processes for one app, that's what I mean.. also, what happens if someone kills amsn, or it blocks, it hangs, it bugs, it whatever ? the background telepathy will stay there, you'll still appear as being 'online' in msn ? what if someone kills telepathy process, we get disconnected and amsn never knows that? how does that work ? > > 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.) > Yes, a bit too much abstracted.. I think there will be a lot of calls from one process to the other... What I don't understand is WHY use 2 processes and do IPC between them when it could be in one process only ? IPC was created to solve the problem where you HAD to use many processes.. we don't HAVE TO, so why do it ? what is SOOOO interesting about this to make us go that way ? It's a huge decision with a huge impact on our final product, the decision shouldn't be taken litely... > 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. > well then, why all this, why have this if we can just call dbus to 'notify other apps' of events, but not use those 'notifications' as part of our own design... also, what about security ? you thought about a simple script that would send dbus messages to any 'telepathy' server and make it think it is aMSN and sends spam/virus to all users ? with IPC, it will be hard to prevent that type of viruses... thought of trojans ? a user controlling the CL of someone else ? dbus being used as a controlling bus is a bit dangerous I think.. again, all speculation, but again, "it's a huge decision with a huge impact on our final product, the decision souldn't be taken litely"... > 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. > untrue... simply use threads, not processes... > > 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. > Yes, I know that, and that's the advantage, using telepathy's API as a base is a good thing, maybe telepathy is good for providing an API, but I don't know about using the lib itself... see previous comments... But then again, I might be wrong.. anyways, as I said, nothing urgent, so we'll talk about this when I get my PC back, and it's better to talk about these things 'live'... Thanks again, KaKaRoTo > > 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 ------------------------------------------------------------------------- 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
