(Illustration by Gaich Muramatsu)
>>>>> "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.pyReceived on 2002-10-16 13:13:25