Re: [Vrs-development] Re: [DotGNU]The Worldwide Computer

[Chris Smith]

On Wednesday 13 February 2002 23:52, you wrote:

> Is this what you mean as a private LDS?

My definition of a private LDS is "an LDS which contains data and resources 
that the LDS owner does not (or cannot) share with the other LDS's in the 
cluster"

This private LDS may in addition share data offered by the cluster (or also 
have data that is *does* want to share).  In which case, the LDS has a dual 
personality based on the resource that clients may want from the cluster.
If they want shared resources, they can get it from any LDS in the cluster 
(technically).  If they want any resources that an LDS has not shared, then 
they must get it directly from the LDS.

> http://subscribe.dotgnu.org/pipermail/developers/2002-February/001985.html
>
> I'm confused about what you are refereing to here.

I was thinking about how you detach the client from the cluster.  The client 
has to find out where a resource is before it can reference it.
Normal LDS's coming and going is really not an issue as the cluster will 
still support the datasets integrity.  Private LDS's are a different matter 
because you really want the service discovery phase to report that a resource 
is 'unavailable' - not when you try and contact it - particularly if you're 
doing so asynchronously (as SOAP is an async protocol!).
However, the usefullness of dynamic service discovery server updating becomes 
really usefull for all LDS's in the cluster as you are able to perform 
transparent load balancing by making all LDS's valid entry points, handed out 
to clients in a controlled sensible way by the service discovery server.

My previous post was specifically about UDDI, but I thought crossed over into 
our current topic and started to offer the beginnings of a solution.

> Then there's the meta-issue of UDDI type interfaces to
> the services offered by a Cluster.
>
> > Unless they're files that are within the sandbox.
> > I think basically they'd all have to be within the
> > Virtual Computer that
> > we're effectively talking about.  If you put a file
> > in the Virtual Computer's
> > filespace, then there must be methods to access the
> > file too.  Now these can
> > be properties of the filespace itself as well as
> > properties of the entity in
> > question.
>
> humm.. indeed they can be

Which I think is excellent.  If we effectively create an abstracted 
filesystem then the development of the application that sits on this is much 
easier.  Can we not use an 'out of the box' encrypted filesystem for our 
needs?

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