language choice of alfs

Joachim Beckers jbeckers at
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 mailing list