All in one email...
David D.W. Downey
david.downey at codecastle.com
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:
> (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 http://www.KiXOLinux.com | http://sourceforge.net/projects/kixolinux/
Member OSWG, LPI http://www.owsg.org | http://www.lpi.org
"Any lad can choose the mundane, but tis the explorers that are truly free in choice!"
More information about the alfs-discuss