Moving on

Jesse Tie Ten Quee highos at highos.com
Tue Jun 12 18:49:36 PDT 2001


Yo,

On Tue, Jun 12, 2001 at 06:40:58PM -0700, Andy wrote:
> Who is actually going to work on the parts? From my understanding, we could
> use different languages for the fe/be, and setup some IPC mechanism between
> them. So we could do the frontend in C/C++, and the backend in perl, or some
> other combination.

Yeah, that's the general idea.

IPC was never fully developed, and most of what was done was in the
heads of us developers and was never put on paper.. the closest thing
that was done for a fe/be implementation was what David was working on
in perl (http://quasar.highos.com/ALFS/).

So this again is something we need to talk about. (i should get Gerard to
open us up a Bugzilla database and start making some TODOs)

The one idea that seemed fairly cool was using XML-RPC which goes over
the HTTP protocol (and even HTTPS if you want it encrypted) (that would
be a general IPC layer, not the actual protocol thou)

I didn't bring this up yet, as it will problably start a hole new
discussion.

> Should the language choice be mainly up to the largest contributors? As they
> will be doing the work, it seems a sensible idea. As we have to make choice
> now, we can either go with the developers-choose-the-language or the
> language-chooses-the-developers theory.

Well, that's why i posted, trying to see if there really is anyone out
there that is willing to contribute time when it comes to coding.

I don't mind learning a new language, but i don't want ALFS to depend on
a whack load of things, id prefer to keep it simple (which is why i
would prefer to stick with C/C++) ... at least for the official
implementation.

(profiles is the easy part, imho, lots of ppl will step up on that
plate)

> Not me :) My C/C++ experience boils down to a few experimentations with Qt
> and some libc experimentations.

Actually the project i was speaking about was done in Qt ;)

> I think this is a bad idea until we get some kind of design document going
> (I'm assuming there isnt one already - im quite new to these lists :). Sorry
> to sound all CompSci, but a design document is a *very* good idea for a
> project where there are multiple distributed developers, all working on
> different subsystems.

You're right there, nothing has been done design wise (apart from what's
up in are heads) which is another thing we need to really talk about.

Argh..and there Gerard just takes off, too late for a bugzilla database
tonight :P

Now.. i'm not some CompSci guy, i don't know all the details on what a
proper design document should look like (i've read a few now and then)
but i've never actually done one, does anyone have any pointers? (URLs)

That would problably be best to start with.

*takes a breath and waits for the next post*

-- 
Jesse Tie Ten Quee - highos at highos dot com
-- 
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