search

remotestorage / spec

remoteStorage Protocol Specification
https://tools.ietf.org/html/draft-dejong-remotestorage
87 stars 5 forks source link

/public #14

Closed justincormack closed 11 years ago

justincormack commented 11 years ago

Can we

  1. not hardcode /public
  2. make it optional instead, as some servers will have no use for public resources and the user might accidentally put something there not understanding this English word

Clearly there needs to be an optional public mechanism, but some servers will be all or mostly public and some not at all, so it should be set by policy no convention.

Will think of some ways in which it can be discovered.

michielbdejong commented 11 years ago

some servers will have no use for public resources [...] some servers will be all or mostly public and some not at all

sorry, i don't understand what you mean here. the servers "serve", and the users "use". so either you mean some servers will not (be wiling to) serve public resources, or you mean some users (or the apps that some users connect with their remote storage) will not use public resources?

the user might accidentally put something there not understanding this English word

the only current client implementation is remotestorage.js, and there this is unlikely. Try out for instance https://sharedy.5apps.com/ - you will see how the user never has to choose a location for their data. It's user -> app -> remotestorage.js module -> remotestorage.js core -> server. The filenames conventions are decided on the 'remotestorage.js module' level. the user only sees a UI that the app exposes, not the underlying json documents or their file paths.

michielbdejong commented 11 years ago

thanks for the suggestion, but i don't think this is a big enough problem in practice to merit making the spec more complicated in that sense