a few decisions
jhuntwork at linuxfromscratch.org
Tue Feb 1 04:24:57 PST 2005
jamie bennett wrote:
> I hate to throw a spanner in the works but for me, parsing the XML from the book
> would be my highest priority. Profile maintainance isn't only a chore it's prone
> to human error. If we could parse the whole of the lfs and blfs books into
> seperate, self-contained profiles, I think we could have a pretty powerful
> system from the get-go. Having each profile self-contained would make selecting
> only the ones you wanted alot easier.
I agree. Parsing the book is in some ways a very low-level function,
and needs to be included from the start. However, as I mentioned in this
original post, our first priority, before we do anything else right now,
is finishing up the SRS that James started. It doesn't have to be
filled in to every excruciating detail before we start coding, but what
I want to see happen is that it becomes the guide for all development
that takes place. When there is a question about what we're intending
to incorporate in the code, or how we're going to do it, we go to the SRS.
> I've thought about ALFS quite a lot lately so just to bring some more discussion
> points to the table :-
> I'm not sure C is the right way to go about this (I saying that as a C
> programmer). Pro's are, of course, that we have a code base to start from now
> but, again IMO, python would be better. Its a rapid language to both learn and
> use and the fact that it is a higher level language wouldn't be detremental to
> the program as most of ALFS's execution time would be spent compiling.
This may be a possibility. IIRC, one of the things that James was hoping
would be useful about the SRS, is that it would define the functions and
methods of the new tool without being language-specific. I personally
am willing to at least test out the possibility of using Python (someone
else mentioned Ruby once, though I don't know if that's recommended) or
a similar language in another branch of the repo.
> My thoughts on how _I_ would do the ALFS client/server model.
> Have the server sit on the D-BUS waiting for client connections. As the majority
> of the time both the client and the server are on the same machine, this is a
> simple model which not only allows the ALFS client to see whats happening but
> any tool that can look at the D-BUS. If we are connecting remotely, the server
> would still be run on the host but it would relay the commands to the remote
> host where they would be interpreted.
Sounds interesting. One point I would like to bring up and clarify:
When we mean we want network capability, are we talking only LAN
networking or do we expect that people would communicate across the
internet with our tool? I ask because if it's only LAN communication
we're talking about here, I personally don't see the need to have our
protocol be encrypted or secured by other similar means.
> As always, this is IMO and hopefully will promote discussion.
Indeed. Any ideas or suggestions let's get out on the table again now,
but again, I'd like to see discussion center around and include the SRS,
which can be found here:
Please read through that - there are still some missing sections we need
to flesh out. I'd like to take a section or two at a time, and make
sure that we're all in agreement to what is there, and/or add to any
missing spots. We can do that here on alfs-discuss.
More information about the alfs-discuss