I've finnished the first version of my (2nd step) IOS Console. It

includes:

- A Connection and cluster control

- A Communication control

- A Function server



The connection and cluster control is the thing required for the cluster

to exist. Mostly automatic, it will make sure the cluster is set up and

that everybody knows the IP's of the others.



The communication control is the user's interface to the IOS network.

This is where requests are typed in and where returns are collected

before they are processed by the Function server.



The Function server is indeed a <b>very usefull</b> little thing: It

allows you to program your own global IOS Functions! Communication is

preformed via the Windows registry in VB-compatible style. The name

specifies how the function is called in IOS (e.g.: A "Find" function can

be called from any IOS console like "remote.find:"), the 3 boxes

corespond to the VB-style App, Section and Key. The Function server will

write the request to the Input registry path, send a primary answer when

it appears from the Answer registry path and finnaly a secondary answer

(again when it becomes a nonzero lenght string) from the Result registry

path.



It is recomended that you test-type in a request for the function you're

about to name, to see if there is maybe an existant function somewhere

already and make sure you don't end up with a function having the same

name as another one that does something completely diffirent. You can

also try making the function name out of your surname just to make

sure... =]



Most IOS functions you <u>install</u> will automaticaly add themselves

to the Function server databank.