All in one email...

David D.W. Downey david.downey at
Wed Sep 6 04:23:34 PDT 2000

hmmm. how to say this...

I've never coded an API before. I'm personally still a very new programmer
so defining any of the syntax would be out for me save maybe as a
balancing check on how technical the docs read. (I mean the less terse the
directions are the greater success rate we'll have on things actually
working when Johnie Q Public tries this thing.

If there were any section that I would be interested in getting involved
in, it would be the networking section. Testing of the API in that regard
would be right up my alley. And in that arena I can get fairly technical
so working with developers of the API is a definite possibility.

One of the things I'm wondering about is if it's possible to code based on
a specific function. aka. While many profiles like what debian has for
their installs are getting fairly detailed in finding out the preferred
use of a system and installing only those binaries, isolation of related
cross tasks would also be desirable. Take for instance an LVS install. You
can have a system configured as a backup or primary node, passive master,
agressive master, replete with choice of 4 algorythms to choose from. Most
only install the base system and you have to go back and hand configure
the LVS/HA software. What if you asked the client at runtime what choices
he wanted. Then pass those to the installer which would allow a far more
granular approach to customization levels.

Instead of just asking if this is going to be an load balancing or a high
availability cluster member, find out what the exact role will be and
write the configs for exactly that. This would allow true drop-in servers.
For the average joe running it at home, they get to choose a standard
workstation install or a standard home server install. Granularity control
at the upper end of customization will make defining network connection
functions at the global profile level rather simple. (hehe I make note
here that I consider the actual coding of those routines to be the hardest
part of the job. Defining is easy.)

I would use something like python for the language of choice for writing
this but I'm guessing that it's already been decided that XML will be

On Tue, 5 Sep 2000, Jesse Tie Ten Quee wrote:

> Yo,
> (Note: most of these go hand-in-hand)
> [-] ALFS
>     [-] Communication API
>         [+] Front-End API
>         [+] Back-End API
>         [+] Profiler API
>     [-] Profile API
>         [+] Profile Functions API
>         [+] Profile Syntax API
> A nice basic "modular" API structure, no?
> The API needs just as much work as everything else and for that reason it's a good idea (imho) to split it up.
> Right now, i (i'll leave the Profile stuff to Bryan/Gerard) want to focus on the actually communication API.
> I'll try and gather my thoughs about it, just wanted to post this.
> Aside from this, i've been working on bootdisks/bootcds and i have quite a few questions on how we want todo stuff, anyways that will come...
> -
> Jesse Tie Ten Quee - highos at highos dot com

David D.W. Downey          Red Hat Certified Engineer   |   Internet Security Specialist        $
KiXO Linux        |
Member OSWG, LPI    |
       "Any lad can choose the mundane, but tis the explorers that are truly free in choice!"

More information about the alfs-discuss mailing list