[Vrs-development] Re: [DotGNU]Re: Network SEE architecture, v2.0.1

[Chris Smith]

On Thursday 10 October 2002 08:43, you wrote:
>
> > I don't know exactly what you mean by "well-defined internal
> > messaging API."
>
> I think he just means that the various LDS nodes in the VRS have
> Goldwater available as a message-passing middleware.  We haven't
> actually defined the VRS API that the nodes will use to talk to each
> other yet (eg: "Hi, I'm node foo, let me join the cluster", "hi node
> foo, we have an updated version of file bar in the shared repository
> you should sync with", etc.)  And I'm not sure what all of this has
> to do with VRS vs. SEE.  :*)

Stephen mentioned pipes and sockets etc as a mechanism by which the various 
processes that constituted the SEE on a single machine talk to each other.
I was saying that the VRS is identical in this respect (ie it also has 
processes that need to talk to each other) but we've abstracted the 
pipe/sockets/message queues stuff into the middleware layer.  Any process 
that needs to talk to another process does so through the middleware API, 
which is well-defined.

This is good as it allows the underlying communication mechanism to be 
changed from pipes to sockets to message queues... anything... without having 
to change the processes wanting to talk to other processes. Certainly helps 
with portablility. And the whole point of the middleware is that it is 
generic - not designed specifically for the VRS (it's been around for years 
in fact) so anyone can use it, and thus may lend itself to the SEE also.

> > However, this is not true of VRS, at least as far as I can gather
> > from the name. A Virtual Remote Server should, IMHO, look just like
> > a regular, single-machine service to the user. Maybe more machines
> > hosting it though ;)
>
> Yes, that's the idea.

And I'd like to see if we can get the VRS to look like a single SEE, should 
someone want to.  All it needs is an entry point that adheres to the SEE 
interface specification.  Interoperability!!

Hmm... I'll dig out an email I sent to Stephen a couple of days ago and 
forward it to the list - it might provoke some further ideas.

-- 
Chris Smith
  Technical Architect - netFluid Technology Ltd.
  "Internet Technologies, Distributed Systems and Tuxedo Consultancy"
  E: address@hidden  W: http://www.nfluid.co.uk