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

[Tim Terlegård]

> > flexibility? If the ASP wants to bill the users,
> > fine, SEE could just
> > implement billing on top of VRS.
>
> If SEE was common to both designs, this certainly
> would be possible.

I now realized that SEE is just about securely running a web service on the 
local host. I guess it's the DEE that does all the network job, making a 
distributed system of SEEs.


> > But it says "allow", so I
> > guess the VRS will allow private data to be stored
> > on a central server. That
> > is, VRS can be used by an ASP?
>
> I think it certainly could be, if the ASP provided the
> bandwitdh and presence that would be of value to the
> individual LDS owner. 

If ASPs is possibly with p2p and p2p results in a _very_ distributed system, 
which is very fault tolerant among other things. Then, why wouldn't DEE want 
this? Are there any DotGNUers in here?

<thinking_loud>
Thinking peer-2-peer. A Virtual Remote Server could be a peer. An ASP could 
be a VRS. All users that want to use the ASP is a part of a larger VRS (that 
includes the ASP VRS) and think they contact a single ASP server, when they 
matter a fact communicates with a cluster. Every VRS node runs a lookup 
service, which enables anyone to browse the web services available on any 
node or browse the complete VRS. A VRS node can also turn this off. This 
allows a VRS cluster to have a single server as a lookup directory (although 
this makes it less p2p, the webservices can still be requested in a pure p2p 
manner.).
</thinking_loud>

> There has been a lot of earlier discussion a while ago
> about the scope of the term 'web services'. 
> dotGNU threads have interpreted it very broadly.  It
> includes for our purposes not only component RPC type
> calls like SOAP and J2EE, but also more traditional
> protocols such as http, and dynamic cgi scrippted web

"calls like J2EE"? You mean RMI?
Web in Web Services must mean that http is used and a web server is handling 
the requests. Providing a service with RMI, Corba or just pure sockets, I 
wouldn't call that a Web Service, just a service. As I'm a programmer I 
myself think of a service as an object that exposes its methods to public 
Internet users. This definition doesn't include any protocol information 
whatsoever. But that's just my own definition...


> > wouldn't that be nice? What if
> > one find that XML is shit and one wants to use Corba
> > instead?
>
> That's exactly what I have in mind.  The protocols are
> plugins that layer over the functional parts.  I think
> this may be anohter area where VRS and SEE thinking
> have differed.

Hmm, sounds weird. Why not make the design in such a way that it'll be easy 
to add new protocols? Actually, in my design/programming tasks during the 
years at school, making the design flexible (even if it's not needed) has 
always resulted in much nicer OO. Often one also thinks "wow, because I did 
like that I can also do like this". It's so cool with design  :-)
And one might regret doing a non-flexible design. One might figure out later 
that "aaaah, stupid me, I didn't think of that, I must be able to do this and 
this as well". But of course, one can't make a design that suits everywhere, 
then one would only need one design for all projects in the world  :-)


> > > * To maximize the security and privacy of data.
> >
> > I'd say "Maximizing security, i.e. providing
> > non-repudiation and privacy and
> > authenticity of the data residing in the VRS
> > system."
>
> Humm ..  I'm not sure that we want to do that in the
> infrastructure.  Although authintication services may
> certainly be an offered service.

Authentication will prevent anyone from running executable code on another 
machine. I'm not sure if this is handled by Pnet though? Should all services 
provided by VRS be accessable by anyone? Wouldn't it be neat to allow certain 
services to be called by certain users? If an admin wants to adjust some 
setting on a machine through a web service, anyone would be able to use that 
service. There must be some authentication here.

In the VRS docs it also says that administration of the LDS is done through 
the use of web services. If there's no authentication needed, anyone will be 
able to admin the LDS.

Do you want for instance a bank to be able to use the VRS? If so, the bank 
needs an assurance that the user can't deny it withdraw a certain amount of 
money. They need the non-repudiation feature.

Maybe it's not one of the goals of the VRS to be totally secure. In that 
case, why is that so?


-- Tim