On Fri, Oct 01, 2004 at 05:14:11PM +0200, Ivan Popov wrote:

(just talking to myself? :)

> I have /coda/slowlink.realm
> Troy has a well-maintained /coda/fast.realm
> Jan has a client.
> 
> I ask Troy to give me write access on his realm on a world-readable subtree.
> I build there a separate tree of my to-be-world-readable files,
> the files being named after their checksums.

In fact, it should be done in a less intrusive manner:

_Troy_ decides to make an intermediate cache of my files for his local clients'
sake, builds a hash-named tree of my files he is interesting in,
and lets his clients (or anyone in the world) to use that tree as a
lookaside repository. He does not need any approval from myself,
except read rights, nor is anyone endangered by using an "unapproved"
repository.

One issue is - which identity shall Venus assume while fetching
the lookaside files?
Reasonably, it should assume a special reserved identity (uid), even
if not running as such - it is a special case anyway.
Then external cron scripts could maintain that uid's credentials it in
a transparent manner.
For clarity, it should not be the uid '0' as that is an identity used
by many of daemons. I _am_ authenticating my uid '0' and wouldn't like to
confuse it with Venus' lookaside fetch rights.

Then Troy would not need to serve his lookaside repository to the whole
world, but just to the clients he likes.

[modular clog makes it trivial to grant tokens based, say, on the client IP ;-]

Well, we can do a very similar thing by using other file distribution
methods for the lookaside caches, like CIFS or even NFS.
But it would be nice to keep Coda being self-sufficient.

If relying on external protocols, we _could_ even teach Venus http,
(which is better suited to whole file fetches than NFS or CIFS), and
then we'd be able to put lookaside repositories on web-sites...
Still, I feel it would be a wrong approach and harder to maintain than relying
on Coda's own nicely replicated, acl-protected and with clean semantics
file access. Www infrastructure is there, that's right, but it is there
for other reasons and is not really well suited for file distribution.

(last remark inspired by 0install discussion about caching and replication
using the web, which for my eyes looked incomparably more painful than Coda :)

Cheers,
--
Ivan