Salaam Nadim:) > Without proper commitment from those that have had a hand in this in the > past (Chahine, M.Elzubeir, S.AlBahra) this might be a more difficult task > than initially imagined (I'm not discouraging you, but rather trying to > encourage the old timers :-). In short, I'm not sure Akka's contributors > would even go so far as to say its ready to be included into a distro (I'm > sure I'm out of line in saying this as I've never contributed to Akka, but > that's my gut feeling from all that I've heard from various people about > needing to rewrite Akka and/or using the Farsi code, etc).
Short answer: Akka is very much ready to be included in distributions. Now you can skip this post unless you want a (much) longer description about the issues with Akka. The problem is more during compilation. In other words, those who suceed in its compilation can definitely use it in a production environment. The issues with Akka can be summarized as follows: - it needs quite a few libraries, revolving around the SWIG tools essentially for the compilation process (but not for use, so if you have a binary for example you don't need it) - the libraries in question have issues due to perl inconsistencies at the internals level, which are causing the compilation problem I am not aware of any issue concerning Farsi. If Farsi support is the issue, Akka is ready for it, all is needed are the keymaps and the glyphmaps (i.e. encoding to glyph mappings) and that's something only our Farsi sisters/brothers or anyone else familiar with the systems used in Iran who can do (if documentation or help are needed, this list is here for it). So what is the solutions for the other issue? - drop the swig dependencies to make compilation less problematic, that means essentially rewriting the client part. It's quite easy, it means using CORBA directly from your favorite language. A few days ago a python rewrite of the client side was proposed, if it's done, I think we could pretty much consider it a replacement for the client side and the compilation issue would be solved - even though a C-binary client library might be better for Arabic enabled text installers for example. The other issues that were raised are essentially the number of dependencies - which is independent from Akka being usable in production environment or not. Akka, the server, depends essentially on 2 libraries at run time (more if you count the standard C libraries but these are necessary for any program). These libraries are: - orbit for CORBA support - fribidi for the bidi approximation now I don't see any valid reason to drop fribidi, if for some reason the problem is dynamic linkage (say, you want it run on a system that doesn't necessarily have fribidi installed), static linkage can be done at compilation time, and if the problem is really fribidi per se for whatever reason, one can either integrate back the Acon bidi code (buggy, of lesser quality compared to fribidi and very specific to the encodings used in Acon which makes it a lot less portable) or rewrite one's own bidi engine (waste of efforts). If anyone wants to drop corba, the alternative would be using another protocol for client-server communication, and can be as demanding as rewriting the necessary libraries/protocols - which is also a waste of efforts. Again, static linkage is there for whoever wants to run it on a machine that doesn't have orbit libraries installed. The short exchange Samy and I recently had on this list was about Mohamed and Samy thinking about dropping the whole client/server architecture if I understood things correctly (putting a static configuration and leave it there). From old discussions, (Moe, Samy, correct me if I'm wrong) the arguments revolved essentially around the dependencies and the compilation issues with swig. As I explained, the client/server architecture is necessary and the static configuration is not a correct approach. To give a real world scenario, consider a common program like midnight commander. Such a program could decide to switch to different modes (Arabic, English, bidi, etc) and encodings (windows, ISO, Farsi, etc) according to the context, and would therefore need to cooperate with the server, kind of like it's done with GPM (the console mouse driver - which btw would need a patch to cooperate with Akka). A static driver (like Acon for example) simply does not allow such interaction. Now to keep using the GPM analogy, unlike Akka, GPM uses sockets for its communication with clients, which is much more common on unix thanks to decades of existence. But that also meant the GPM folks had to develop client libraries and the communication protocol in order to use it. Thanks to 30 years of progress, we have CORBA and we are spared that stage. If anyone wants to throw CORBA anyway, be my guest, but the client/server architecture is needed, so you'll have to find an alternative (and if the alternative is sockets, you'll have to write the communication protocol and the Akka libraries to use it). Hope that clears it up, Salaam _______________________________________________ Developer mailing list [EMAIL PROTECTED] http://lists.arabeyes.org/mailman/listinfo/developer
