language choice of alfs
zhouhui at wam.umd.edu
Mon Dec 20 12:58:40 PST 2004
On Mon, Dec 20, 2004 at 08:49:08PM +0100, Joachim Beckers wrote:
>IMO, the backend should be written in some compilable language, like C
>or so. That's important because it will have to work under heavy loads
>when parsing profiles,
The existing profiles for lfs is not 'heavy' at all. The whole blfs
profile may be heavier, but again the parsing part only happens at
initialization, a few minutes compared to hours of building time
really won't bother a lot of users. Once the profiles includes
packages as many as those in debian depositories, it is indeed heavy,
but at that point, a better solution is to split the profiles into a
data base, otherwise, even a fastest engine will feel slow.
>copying files, building packages,
nALFS spawns shell run these tasks. Unless all these tasks were
recoded in alfs, language choices won't make measurable differences.
>packages' output and details, aso.
If the logging is just streaming out to a file, the overhead of these
is immeasurable, unless the logfile has a complicated structure and/or
alfs need do some formating before output. In most case, the IO
shadow's every thing.
>I personally wouldn't trust a script
>that's doning all that. As mentioned before: scripting languages just
>weren't designed for such tasks.
On the contrary, scripting languages such as perl is especially designed
for these tasks. They work like a charm to glue together tasks such as
compiling and linking.
>For the frontend, I don't care which language we use. Developing a
>frontend should be quite easy once we have docs describing how to
>interface with the backend.
It's funny I think the opposite. The backend deals with a finite set
of data and just runs applications on these data. Once the structure
of these data is defined, there is nothing complicated. On the other
hand, the front end deals with human, which is an infinite set. Of
course if the designer willing to let the user to compromise, and
offer just a shabby interface, it is easy. But once start to
considering the user convienience or friendliness, it is a never
ending business. The way I see it, the developement of GIMP is mostly
on the UI part which is the exact place makes Photoshop so much
better. It is not clear yet, but I assume the task of analysing the
command output and produce a nice summary or progress to the user is
in the frontend, which could be the most heavy part in alfs.
>PyGTK, GTKPerl, Tcl/Tk come to my mind, but
> C/C++/C#/Java/VB are possible too (although I have some thoughts about
>VB not being a real programming language).
>However, for the *official*
>frontend, I think we should go for the backends's language, for obvious
>reasons of maintainability.
I don't see the obvious reasons ;-)
IMHO, if the functionality of frontend and backend is clearly divided,
there will not be much need to share data structures, so either can be
implemented independently, which could be a very nice thing.
More information about the alfs-discuss