All in one email...

Jesse Tie Ten Quee highos at highos.com
Wed Sep 6 08:56:46 PDT 2000


Yo,

On Wed, Sep 06, 2000 at 06:23:34AM -0500, David D.W. Downey wrote:
> 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.

So am i, but i'm willing to get work done, so i'm not going to let that stop me =)

> 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.

You mean Communication API (which is exactly that, communication between each subtool (Front-End, Back-End, Profiler), thinking about using Sockets and a form of Netmessages to keep it generic...

> 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.

That's the general idea.

> 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.)

That's what you think...

> 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
> used.

The point of making (this) API is so where not stuck with one language to write everything in.

I favour C++ (with Qt when GUI), Bryan loves Perl, you like Python, etc...

-
Jesse Tie Ten Quee - highos at highos dot com





More information about the alfs-discuss mailing list