Function spliting between front and back
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,
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 :-)
More information about the alfs-discuss