Salam, Chahine <snips>On Thu, 2003-07-31 at 02:45, Chahine M. HAMILA wrote: > Short answer: Akka is very much ready to be included in distributions. > 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. I am still trying the python approach. 'Trying' means some problems: I have always used omniORB (not an option here - an additional dependency), but tryig now to use ORBit. The python support for ORBit is not that good (essentially unusable) in Red Hat 8+, but the support for ORBit2 is good. I am thinking of upgrading akka to use ORBit2, and I think it is simple with your help. The text installer in Red Hat is python, so if distros have python working, this will not be a problem. If any problems, I may switch to a C client, but I will also prefer an upgrade to ORBit2. I am also in support of using CORBA in this project. > > 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). Now redhat 10 includes fribidi, and as debian already has it, it's fair to say it's the unicode bidi library of choice, don't drop it.. > > 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. CORBA is already included with GNOME (ORBit), so most systems will have it arlready installed. Not a problematic dependency. > > 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 > Developer at arabeyes dot org > http://lists.arabeyes.org/mailman/listinfo/developer -- Muhammad Abdulmuneim Alkarouri Teaching Assistant Dept. of Electrical and Electronic Engineering Faculty of Engineering and Architecture University of Khartoum Khartoum, Sudan
Attachment:
signature.asc
Description: This is a digitally signed message part