On Wed, 16 Oct 2002, Kevin Atkinson wrote:

> On Wed, 16 Oct 2002, Stephen J. Turnbull wrote:
> 
> > >>>>> "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).  
> 
> How has the client gone disconnected?  I never said that.
> 
> > 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.  
> 
> What exactly do you mean by "reliable stream"?
> 
> > 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.
> 
> Actually SMB over 100 GB network works just fine for for burning a CD 

GB should be MB sorry.

> image over the network.  I have done it several times before.
> 
> > From your requirements, it sounds to me like what you are describing
> > as ideal is something like WebDAV
> 
> I will have a look but I think I will stick with my current system of 
> manually copying files around.
> 
> 

-- 
http://kevin.atkinson.dhs.org