language choice of alfs
jwrober at linuxfromscratch.org
Mon Dec 20 19:52:16 PST 2004
Hui Zhou wrote:
> 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.
Remember that the new alfs tool is going to do a lot more validation and
parsing of profiles than in the past. There is going to be a need for
lots of threads to be running simultaneously to have things keep up. I
would bet that some kind of event system will need to be implemented in
the back end so that the front end will know what is going on and to
keep all the threads in check.
>> 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.
I do not think that the handlers in current nALFS are going to be used.
IIUC, the new alfs tool will do that stuff differently.
>> logging 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.
Logging will be in an XML DTD based file. See the SRS on the wiki.
>> I personally wouldn't trust a script that's doning all that. As
>> mentioned before: scripting languages just weren't designed for such
> 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
> 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