3 ms·
I'd also point out that URLs aren't exactly pointers as they don't (all) support writes in addition to reads. It'd be interesting to see a webservice support lo
by joshma 14y ago
I'd also point out that URLs aren't exactly pointers as they don't (all) support writes in addition to reads. It'd be interesting to see a webservice support locking, reading, and writing from URLs as pointers.
- brettcvz 14y agoWe do read/write, re. lock would you want to prevent all reads? Do a 503 or just hang the connection until the lock is undone?
- joshma 14y agoNice, didn't notice that! (For those interested, it's actually documented here: https://developers.filepicker.io/docs/web/#fpurl-contents https://developers.filepicker.io/docs/web/#fpurl-contents) A 501 sounds like the closest error code, and I'd say having both asynchronous and synchronous modes of locking might be useful. Synchronous just holds the connection open (certain frameworks don't mind long-lived connections) while an asynchronous method might pass in a callback_url in the request to be hit when the file is ready, in the case of lockage. (NB: to be honest I'm not too sold on the demand for locking vs ovewriting, I guess I threw it in the list of [things that files can do]. Might be interesting to see this need evolve as files move to the "cloud" though.) EDIT: While I'm at it, a PUT method for creating files could be cool too, to let people use filepicker without the JS widget. // oops, missed the link. meant to reply to sibling comment
- icebraining 14y agoI'd also point out that URLs aren't exactly pointers as they don't (all) support writes in addition to reads. return &"Read only data";