Re: [Vrs-development] VRS and SEE/DEE goals

[Bill Lance]

--- Chris Smith <address@hidden> wrote:
> 
> 
> Remember the 'proxy' thing that we discussed a way
> back?
> That came about whilst we were considering
> non-static
> resources. The above points qualify a non-static
> resource,
> and through the approach of LDS's keepeng these
> resources
> local, I think we can facilitate dynamic content.
> 

Ya...  hummm.  This has always been a tricky spot. 
I've really ressisted the idea of the LDS having
direct access to any part of the host's file structure
outside of the LDS's root.  This is for the obvious
gaping security hole it opens.  Of course, the
necessary file tree can simply be mounted within the
LDS root, where it would be visible to both the still
secured LDS and to the host systems root admin.  

We have talked a bit about how an inode model in the
Repository Manger would allow us to load a hiearchial
file system into the distributed Reository.  But,
frankly, the complexity of that kind of shakes me a
bit, not to mention the network traffic it would most
likely cause.  Also, it most liekly would substantialy
increase the amount of data stored in the Repository. 


It should be a fairly simple matter to direct all
requests to the LDS home of the service at the Service
Request Routing stage.

But, my question then is, why not just run the service
directly on the net with a dedicated service.  Since
the service is completely attached to that host
anyway, there is little value that a VRS adds, except
for exposing the service through a different ip
address.  Althought, come to think of it, that might
in itself be quite useful ....  hum.



> 
> I'd rather see the members of an VRS be controlled. 
> 
> 
> > Although, I suppose it would be quite possible to
> run
> > a VRS that would accept anyone, I don't see a
> reason
> > to do this.  But there most certainly might be one
> > that I just don't see.
> 
> I've been viewing the VRS as 'open' because it's the
> worse case scenario - and someone's bound to ask for
> it.  If our architecture will support this, then
> it's
> a bonus - even if it's never used...... however,
> like
> I said above, it's a real nightmare.
> 

not to mention that it runs counter to the lessons of
biology.



__________________________________________________
Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards®
http://movies.yahoo.com/