Re: [Vrs-development] The Virtual Remote Server Functionality

[Bill Lance]

--- Chris Smith <address@hidden> wrote:
> 
> I assume you're refering to the service access
> modules.  ie HTTP access being 
> provided by Apache, with others defined on a need
> basis.
> The static content to which you refer comes from
> within the invoked 
> webservice not traditional static resources to which
> Apache has access??
> 
> 

Exactly.  These static resources are drawn from the
Repository.  I'm not at all sure how to handle
configuration files yet. Concievably, they too can be
in the Repository.  But bootstraping them in there
might be tricky.



.
> 
> > Level III - Encapsulated total Server System
> > The last level is the most ambitious of the
> targets.
> > It depends on the Repository being able to store
> and
> > retrieve a total hiearchial file system that can
> > include not just data files, but native
> executables as
> > well.  It also depends on being able to run those
> > executables in a sufficently stronge sandbox to
> meet
> > the security and privacy requirements of the
> system
> 
> Hmm.  I'm slightly concerned on how you manage
> 'native' exe's.  Surely you'd 
> want them to be in bytcode, as you can't guarantee
> the platform on which 
> they'd be deployed.

well, as I mentioned, this IS the most ambitious
target.   :)

Your quiet right that this level will be platform
dependent by virtue of 'native exacutibles'.  The
first two levels might, just might, live with stronge
enough internode communication protocols that the
nodes can run on different plateforms.  But not this
one.  Even Linux and BSD mixed might not work. 
However, of course, any platform can make services
requests, juat as with a regular Linux/Apachie server.

I never really expected to be able to mix Linux and
Windows in a Cluster anyhow.  Microsoft's move in XP
towards automatic system updates, teathered to MS
servers, is the last straw.  This makes security and
privacy on future MS products an oxmoron.  At least
before, most of their explotes were errors and
unnintended side effects.  Now it will be built in as
a 'feature'.  (Amazing,  absolutly amazing !!)

> You're quite right in wanting 'controlled' native
> exe's on controlled 
> machines.  These resources would NOT be distributed
> as part of the VRS data 
> set, but anchored to the machine on which they were
> deployed.
> How you sandbox these is interesting - you could do
> the CGI trick of chroot 
> and ulimit etc, but you have the fork-exec server
> hit, which is not nice.  
> Some sort of 'ready to run' state would be good -
> perhaps done through a 
> cache of most recently invoked executables.  ie,
> once an exe has run it 
> lingers for a short time ready to accept another
> request.  The time window 
> during which it lingers should be based on the
> frequency of requests for it.
> But this is very complicated.  Very complicated. 
> You can abstract the whole 
> 'how we get an exe and run it' into a box and TRY
> and build in this kind of 
> optimisation later - but it is very complicated!!
> 


<sigh>  Really.  I can see the problems here, but I'm
not smart enought to see the soltions.






__________________________________________________
Do You Yahoo!?
Send FREE Valentine eCards with Yahoo! Greetings!
http://greetings.yahoo.com