add getFileSize() as an experimental feature

[michielbdejong]

everybody except me seems to agree that HEAD requests are very useful. https://github.com/remotestorage/spec/pull/21 so let's implement them emulated first. if they become supported in -02, then we need to emulate them anyway for -00 and -01, by doing a GET request and then determining the size of the data received

[michielbdejong]

or maybe what module devs (supposedly) need is a function getObjectIfNotKnownToBeBig(), which would only do the HEAD requests if it is actually supported.

note that module devs should only use this when they think the object might be big. otherwise it just causes one HEAD request to preceed every GET requests, which is silly and slower instead of faster.

i think adding the api call first, and seeing if any module dev uses it in practice, would tell us a lot about how useful HEAD requests would actually be.

i know the fuse client is capable of using HEAD requests as an experimental feature. there, it's true that it's needed for compatibility with how fopen() works, and a speedup is achieved there. but since the main use case for remoteStorage is in the browser, i would not want to optimize the spec for use as a mounted file system

[raucao]

In my opinion we should stop anticipating what developers want to use exactly, and just give them the low-level tools to do implement it themselves. See e.g. this talk for why this is important for Web technology specs: https://www.youtube.com/watch?v=EcyxXPILO8E

[raucao]

I don't really understand what the problem is here. As someone else already said, it's such a minor change and so easy to implement, that there's no reason not to do what HTTP recommends.

[michielbdejong]

@nilclass just mentioned a more realistic use case: a module should be able to deal with random files showing up spontaneously, because users just drop files in their storage. it can then do a HEAD request to find out the content-type. so the core library could expose a getContentType() function that would rely on HEAD whenever the server supports it.

combined with the fact that the http spec is so clearly in favour of implementing HEAD everywhere, and that everybody else seems to want it added, i'll change my opinion to HEAD: include in -02, Content-Length: postpone to -03.

[raucao]

Yay! :)

What's holding us back for content-length? I think we already support that at 5apps, and it's equally simple to implement.

[nilclass]

I think we still should add Content-Length (and the getFileSize for that matter).

[michielbdejong]

i think we should try to never ever change the spec again. just leave it as it is now, for the rest of eternity. that is what would make me happy :)