>>>>> "Kevin" == Kevin Atkinson <kevin_at_atkinson.dhs.org> writes:

    Kevin> Instead of treating partly retrieve files as file fragments
    Kevin> or blocks why not simply treat them as that.  That is
    Kevin> instead of insisting upon retrieving the whole file simply
    Kevin> retrieve the part requested and mark the file as partly
    Kevin> retrieve on the client and just the client.  The server
    Kevin> does not need to worry about which parts the client has, it
    Kevin> only has to worry that it has some parts thus simplifying
    Kevin> things greatly.

Not really; the server already does not worry about what the client
has (the client may have gone disconnected, remember).  The complexity
Jan is describing is entirely client-side.  The problem is that
programs expect "reliable stream" semantics as well as "random access
block device" semantics from files, and your scheme emphasizes random
access to blocks at the expense of stream reliability.  Consider: with
current Coda design you can drive a CD-RW from an image on the Coda FS
(assuming a pretty unloaded or very fast system).  With your design, I
think not.

>From your requirements, it sounds to me like what you are describing
as ideal is something like WebDAV, not a filesystem as such.  WebDAV
uses HTTP as transport (thus you can request fragments of limited
size), and provides facilities for conflict and version management.
With proper client design you could have caching, too.

Don't ask me about clients, that's the extent of my knowledge about
WebDAV.

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
 My nostalgia for Icon makes me forget about any of the bad things.  I don't
have much nostalgia for Perl, so its faults I remember.  Scott Gilbert c.l.py