Moving on

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


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 (

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

> 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

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

> 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
and put unsubscribe in the subject header of the message

More information about the alfs-discuss mailing list