jwrober at linuxfromscratch.org
Tue Feb 1 07:30:01 PST 2005
Started another one as well.
To tell you the truth, I don't really care any way to Sunday what the
new tool is programmed in. I just want it to work. Here are my
thoughts on the matter to start discussion.
If we chose C for at least the daemon, then we don't have to add a
dependancy (really another package) to a base LFS (or in our case the
LiveCD) to do the building. On the converse, one could argue that we
already require libXML2, wget and curl so what is one more!
I have never touched pyton, so I have no frame of reference. I have
seen it in action in lots of RHL tools and their build system
(installer). The stuff that runs in X is nice. Can we get a GUI like
what python does in X in a console window? The client would need to
have two versions as I see it. Once that runs in a console window off
of the LiveCD and one that can run in X on the same LiveCD or on a
remote box over the network.
I want the daemon to be be as fast as possible. This probably should be
added as a requirement in the SRS under performance. Can an interpreted
language like Python be fast like C? Since the client is only sending
commands and recieving feedback (like an ftp or ssh client) then speed
is not really an issue, but usability of the interface is. This should
also go into the usability section of the SRS.
These thoughts should go into our decision on language(s) to select.
This is why an SRS is written ahead of time. if we get all this down on
"paper" then it makes it easier for all of us to make a decision.
More information about the alfs-discuss