language choice of alfs
jbeckers at linuxfromscratch.org
Wed Dec 22 02:50:52 PST 2004
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, copying files, building packages, logging
> packages' output and details, aso. I personally wouldn't trust a script
> that's doning all that. As mentioned before: scripting languages just
> weren't designed for such tasks.
> 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. 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.
After reading Hui Zhou's posts i realize he's quite right. However I
still think that the backend should be written in a compilable language
for performance reasons. And developing a frontend can be as hard or as
easy as you want to make it. Someone could do a frontend as a shell
script for example, but it will take a lot of time and it will be very
hard to do. On the other hand there are languages that have everything
you need (networking, xml-support, ...) built-in, think of java, php,
c#. Maybe this makes my point a bit clearer.
Something different that came to my mind yesterday: Is it possible to
run a script as a daemon? If not, the idea of a "alfsd" backend isn't
realizeable with a script.
More information about the alfs-discuss