Op dinsdag 18 juli 2006 19:45, schreef Philippe Valembois - Phil: > Hi, > even if you yield at us I am happy ;) > I am sure now that all will be in Tcl except protocol and bindings for > D-Bus... > Now, to sum up a little we will have : > Protocol and Thelepathy <-> Some IPC service (DBus on *Nix, maybe DCom on > Win ?, MacOs maybe DBus) <-> Bindings for IPC written in C (no need of C++ > neither GLib for that) <-> aMSN logic with XML2GUI (written in Tcl) <-> GUI > plugins (like XUL created by Harry, TkHtml created by Tom, Boris and me, > and maybe others) > I like that :d Not me. That is, I see a few problems. To begin at the end: I don't think it is a good thing to have multiple GUIs, even though it would be possible, I think we should just choose. TkHtml is nice, XULRunner is better, so we use XULRunner. And what would you care if the login screen, contact list, etc, which are XHTML are viewed by XULRunner instead of TkHtml? And how would you create the dialog windows in HTML? XUL is much more fit for that!
Then the way the GUI is bound to the rest. Probably there will be a thin layer in C++, that will be pure stubs. (By the way, if possible this will be in C, but i suspect it will need to be C++.) Anyway, they will provide a pure C API. Then on the protocol side we have the Telepathy API, for which we'll use the C implementation with GLib. Then we have libamsn2_tcl that will provide the TCL bindings for all that stuff, in a way as generic as possible, and as much as possible similar in style to the standard functions in tcl/tk, so everything will really 'feel like TCL'. Then at last we have the 'core plugins', written in TCL, that implement the actual application logic. Level 4: (Core) Plugins Level 3: TCL bindings, event system, plugins management core Level 2: Generic API for GUI, Telepathy API Level 1: XULRunner, Telepathy Connection Manager (Note that the GUI XML files themselves are part of the plugins in Level 4) This may seem complex, but it is not, it is just a layered design in another way than you propose. You go from Protocol to GUI, I go from low-level code (close to system libraries) to high level (application logic), the high level being in TCL. Plugins can be freely added and removed. We as developers can add and remove core plugins, and users can decide themselves which additional plugins they want to load. > So there will be many Tcl and people will have the ability to develop > something in Tcl As you see, that was already so in the design. It may be only one layer, but that layer will have much more code in it than the other 3 layers together! (Not counting the parts that are not in scope of our project.) > Now there is a little problem (no don't worry I am not whining it's only to > have a good design) : plugins... > Because there are some plugins that interact at protocol level and some > other that interact at GUI level and maybe some that interact in the two > levels... But I think that doing plugins for only one GUI is a silly > thing... aMSN is aMSN and plugins should be for aMSN and not for a > whateverGUIpluginforaMSN... So we should think too about a way to make > plugins compatible with all GUIs... As long as any GUI can handle XHTML and XUL, and implements the Generic API for GUI that won't be a problem. (Note that the core plugins will already enforce these requirements, so any GUI system that does not meet those requirements, simply cannot be a GUI for aMSN2!) > Phil > P.S. I hope I well understood your mail Youness. > PPS Windows has already its IPC techniques so we should use them to port > DBus to Windows but it's not our job (at least not the job of aMSN > team).... There are efforts going on to port D-BUS to windows, but it seems to be difficult. We should monitor that. If D-BUS for Windows is ready before aMSN2 gets into Beta stage, there is no problem at all. We can do without Windows in early development. If a real problem arises, we should go with a non IPC implementation of the same API as used by Telepathy. (Implementing the API based on another IPC system will take more time than do the same with multi-threading within the same process, which is possible on Windows. The only disadvantage would be that other processes can not receive the signals, but that feature won't be used on Windows anyway!) > > > ------------------------------------------------------------------------- > 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
