ac_ml at backslash.co.uk
Tue Jun 12 19:52:24 PDT 2001
From: "Jesse Tie Ten Quee" <highos at highos.com>
> 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
> > use different languages for the fe/be, and setup some IPC mechanism
> > them. So we could do the frontend in C/C++, and the backend in perl, or
> > 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)
That opened up a nice can of worms, there :)
> 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
> > will be doing the work, it seems a sensible idea. As we have to make
> > 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
I can totally understand that. The problem with C/C++ is that the languages
arent really designed with text processing in mind. What could be done,
however, is write the backend in text-processing-happy perl with the
frontend in C++, nice and perty Qt or something.
> > Not me :) My C/C++ experience boils down to a few experimentations with
> > 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
> > (I'm assuming there isnt one already - im quite new to these lists :).
> > 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)
I'm a bad CompSci guy. Whatever describes what you want to do, how you'll do
it etc will probably be good enough. If the fe and be are begin developed
seperately, then interfaces between them would probably need to be defined
then, to sooth teething problems.
> That would problably be best to start with.
> *takes a breath and waits for the next post*
One thing that should be considered a must: internationalization. Most
coders out there probably have very little or no experience of i18n matters,
so I think these should be considered in the design document. This means no
hard coded strings for UI stuff etc. Not too hard, but we should include it
in the standards specs, so we dont wind up with too many problems down the
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