Re: The RedHat Project ?

["Chahine M. HAMILA" <mch at chaham dot com>]

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