[sstorm-discuss] Re: SandStorm, etc.

[Idan S. <i_...@ya...>]

On 20 May 2001 02:15:42 +0000, Michael Hay wrote:

> You are right on about the XML-RPC message which I had a sample for.  For
> all intent and purpose if the C-Kernel has several embedded interpreted
> languages--service providers, then these internal service providers should
> self register and let  the kernel know exactly what services are available
> to run.  These services could  then be published upstream to a central
> registry (which could use a master LDAP process for registry storage).  At
> this point service requestors would then be required to contact the
> registry (The registry could actually be a set or series of rank-able
> server processes each providing access to registry for all clients.  By
> having a loose cluster of registry processes hopefully, availability issues
> related single points of failure can be eased.) to determine the location
> of the service provider capable of servicing the client's request.
> 
> I am having a hard time writing the rest of this--me think's I took too
> many advil for my massive headache.  At any rate John Goodman is going to
> adapt an LDAP paper and do some additional research on the subject to
> determine if it might be something suitable for registry storage.   Let me
> know what you think so far...

I like the idea of having embedded web server. Currently for optimal
performeance you need to use Apache with all of it's mods, but apache is
heavy-weight, slow, and not optimized for low-latency.

So it will be really usefull to have a clean web server, with embeded
interepters, optimized for the low-latency requirements of SandStorm,
and will also have built-in registry.

I also like the idea of having one "master" registry, and the rest
functioning as "sub-registries", updating and quering the master
registry(which should also have a backup secondary registry).

What i dislike however, is the adaption of LDAP for the registry. The
base for everything should be XML-RPC. i have nothing against LDAP
front-end, but it should not replace the base XML-RPC interface.



Idan.