Function spliting between front and back

Jeremy Huntwork jhuntwork at
Wed Dec 22 11:44:10 PST 2004

Hui Zhou wrote:

> 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 :-)

There's already been some documenting on decisions that were reached 
earlier concerning this.  Consult the Wiki in the ALFS section.

Jeremy Huntwork

More information about the alfs-discuss mailing list