W3C home > Mailing lists > Public > public-xg-webid@w3.org > February 2011

On behalf of

From: Nathan <nathan@webr3.org>
Date: Fri, 04 Feb 2011 13:13:45 +0000
Message-ID: <4D4BFB89.6000503@webr3.org>
To: WebID XG <public-xg-webid@w3.org>
Hi All,

An increasingly common use case on the web, and one we may need to 
factor in, is the mashing of computations and continuations, as outlined 
in CREST [1].

A common model outlined in the CloudStorage DI [2], is to separate the 
applications from the storage, such that each x in the (rough) model 
below is a data source, and the app is running in the agent (client 
side) with auth being peer to peer, app to data tier, as enabled by web id.

   x   x   x   x   x
    \  \   |   /  /
     \  \  |  /  /

However, if we factor in services which mashup data, as below where each 
s is a service:

   x   x  x   x   x
   \  /   |   \  /
    s     |    s
     \    |   /
      \   |  /

And we suppose that each x is ident/acl controlled, then s will need to 
contact x on behalf of the agent. We currently don't have a solution for 
this (?)

Such that currently, each agent would have to GET the data from x, pass 
it to s for computation, then GET back the result from s - which means s 
would be handling private data, and thus would need to be trusted.

  x    x    x
   \   |   /
    \  |  /
     |   |
     s   s

Alternatively, each s could be an agent with a webid of it's own, and we 
could give a acl access to our x's - loosing the distinction between 
services and user agents, such that we just have agents, and agents have 

   x   x     x     x   x
    \   \    |    /   /
     a - a - a - a - a

Or perhaps, we have data storage agents, thus making no distinctions at 
all, and everything is just an agent


I'm unsure which of these models is optimal, and whether we can preclude 
any, or have to cater for each, but it may be good to spend some time 
thinking about it.

[1] http://www.erenkrantz.com/CREST/
[2] http://www.w3.org/DesignIssues/CloudStorage.html

Thanks to Joe Geldart (@arnia) for pointing this out.


Received on Friday, 4 February 2011 13:15:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:06:22 UTC