Moving on

Skip Gaede sgaede at mediaone.net
Tue Jun 12 20:56:50 PDT 2001


I second Andy's thoughts. Let's get a design down on paper and then
we can discuss what goes in the first release, the next release, etc.
After the building blocks are properly arranged, then we can argue
about what language should be used. Actually, the design should be
expressed in terms of modules that have specific inputs and outputs
(or messages), and how the module is actually implemented shouldn't
matter very much.

--Skip

P.S. I'm willing to take a look at the perl code and see what's been done
starting next week. What's wrong with the way the code works today?

-----Original Message-----
From: alfs-discuss-owner at linuxfromscratch.org
[mailto:alfs-discuss-owner at linuxfromscratch.org]On Behalf Of Andy
Sent: Tuesday, June 12, 2001 11:32 PM
To: alfs-discuss at linuxfromscratch.org
Subject: Re: Moving on


From: "Jesse Tie Ten Quee" <highos at highos.com>
> Yo,
>
> On Tue, Jun 12, 2001 at 11:10:19PM -0400, Gerard Beekmans wrote:
> > Simple math, we just need a 'coder'. Do you want to be the coder?
>
> And as Andy just pointed out a very good idea.
>
> We can always keep perl as the be for now and get a working IPC
> in place and i'll start messing with C++/Qt and Qt's XML Objects,
> there's no reasons we can't all work together.
>
> And again, i hope i didn't come off as a total ass in my reply ... for
> everyone that doesn't know Simon or Myself, trust me, we don't take
> things personal and are good friends, just the french in us speaking up
> i think, Eh? (hey, i grew up in Quebec too ya know *g*)

I strongly suggest we then build the design document *now*, before any
further work is done. I don't mean to sound prudish, but this should be
considered essential for the seperate be/fe stuff.

What could be an idea is to use a modular fe/be system. This is slightly
further fetched than the ideas flying around right now.

We could add another layer to the backend, which provides the facility to
grab the packages from a multitude of locations. For instance, for deploying
on a network multiple times, grab the profile and packages from a HTTP
server, with a be module that supports this. Another module could be written
to grab things from CVS, another from a CD. This would provide a great deal
of flexibility for deploying ALFS.

The same idea could be used for the frontend, where the IPC interface with
the backend is language neutral. You could write a silent frontent, a nice
graphical one using a X server, one that is silent except it reports back
the result to an admin via email, etc. If we design it properly (and that
means creating a design doc, sorry to push this idea so much :), then we can
avoid a great deal of hastle (and limitations) in the future.

What do people think of this?

ta, ./andy

--
Unsubscribe: send email to alfs-discuss-request at linuxfromscratch.org
and put unsubscribe in the subject header of the message

-- 
Unsubscribe: send email to alfs-discuss-request at linuxfromscratch.org
and put unsubscribe in the subject header of the message



More information about the alfs-discuss mailing list