dvfs api and toolkits

[P. Kaluza]

Hi List,

Sean Middleditch wrote:

>Some backends might have relatively efficient support for seeking, and
>it might be possible to design the API in such a way that it can
>transparently support either native seek support or local-copy
>emulation.  Doing that could get tricky, though, in some cases - what if
>you open a large file on a backend that doesn't handle seeking but just
>stream it in?  Should the system try to create the temporary copy
>anyhow, or should the API require the developer to explicitly state, "I
>want this file to be seekable" ?
>  
>
I'd say definitely the latter. It should be quite acceptable to API 
users to have to specify a SEEK_NEEDED flag on opening. Then the daemon 
can fork the incoming stream from the first byte. (I think most 
browsers' http backend work this way too.)

However, the point made about caching (for nautilus thumbnailer + 
opening app) is valid too - but maybe more of a corner case, especially 
in the near-to-medium future, where nautilus maybe uses DVFS, but most 
called apps won't yet. So if this is implemented, please make it 
configureable.


Another thing i was just thinking is this: there are _already_ two file 
system semantics under unix, namely POSIX and AFS/CODA. We don't like 
posix, but it probably would make sense to try and stay compatible to 
the afs/coda semantic, if it roughly fits your model. It basically works 
like this: open document for writing, write around in it (write out 
completely or append in D-VFS' case), then close, after which the actual 
writeback to the server occurs (also some basic version control in 
Coda's case, but thats an area   D-VFS could tackle later, if at all). 
So basically an atomic-write-on-close. So in the case of DAV, you would 
MKACTIVITY, stream the file to the server (in the chunks sent by the 
app), and then, on closing, move the file atomically over the original. 
Does this sound sensible ?

Bye,
  Philipp