Function spliting between front and back

Hui Zhou zhouhui at wam.umd.edu
Wed Dec 22 09:00:31 PST 2004


There have been some discussions before on the functions of front end 
and backend before. However, those occured on the code base of nALFS. 
Now we have a concensus to start from scratch, should we disscuss this 
issue once more and make it easier and clearer to go to the document?

At the minimum, the backend need deal with the actual building such as 
running configure, make and make install. Every thing else can be 
dealt with by the front end including parsing profiles and retrieving 
packages. The benefit of this approach is the front end has no 
restriction and can implement many functions such different front end 
parsing different profiles, deal with all kinds of packages (cvs, 
patch, ...)

There is also maximal approach that the backend does the whole thing 
and the front end just serve as a terminal(translating user input and 
displaying status or messages).

Which way is alfs leaning?

In either way, I think we still can do it in a unix way: Implement 
each function individually as seperate programs. This way, each 
utility can be programmed independently and possiblly attract more 
developers. There were some tools such as install-logs and lfscmd 
which can just plug into the whole alfs scheme (probably both need 
alfs touch though). If we pump all the messages including that of 
make, gcc and alfs system messages) to a udp port, we probably can use 
a seprate program to analyse the logs and do the final log formating.
I am not sure how it can be done to pipe the messages if no listeners 
are availible. The way I did it is dump to a file and another program 
tracks that file. However, the buffered IO could be a problem but 
there is walk around.

Just some rambling to trigger the talking :-)

-- 
Hui Zhou



More information about the alfs-discuss mailing list