Re: [apps-discuss] Non-proprietary sync (was Re: Is e-mail going to die?

["Michiel B. de Jong" <[e-mail]>]

Hi Mark,

On 2013-07-04 07:34, Mark Nottingham wrote:
> Hi Michiel,
>
> I'm very interested in this area; I think we need open standards here
> desperately.

Great!

> I potentially have a lot of feedback for you (both editorial and more
> substantial), but wanted to first know: what is the remoteStorage
> community's intent in publishing this draft?

we hadn't really formulated that until now, so we had a little 
discussion about it; we didn't entirely finish discussing it yet, but 
overall i think most of us agree that the ietf would probably be the 
right platform for developing the idea of remoteStorage further.

we started working on this spec as an open source project because we 
identified a need for one - its development so far was partially 
financed by donations, partially by people donating their time.

It's of course scary to give up control over something we care so much 
about, but we also trust the ietf would do a better job at guarding the 
public's best interest than our small community of quite inexperienced 
volunteers. :)

> I.e., do you think you're nearly done, and just need to publish a
> specification?

it's becoming quite crystallized within its very limited defined set of 
features. you can get an idea of what we consider outstanding issues by 
browsing https://github.com/remotestorage/spec/issues our current 
process is to go through that list twice a year, and see which of those 
issues merit a text change. we are trying to change as little as 
possible each time, to avoid an entropy walk into feature bloat. :)

> Are you willing to consider substantial changes to the
> specification, even if it breaks your current implementations if
> there's good reason?

yes, we do this every 6 months anyway. what type of changes did you 
have in mind?

so far, even though these are themes that continuously come up as 
requests, we have resisted adding for instance:
- byte ranges on GET (and PUT?) requests,
- query parameters like sorting/filtering/paging,
- access control lists,
- long polling and/or other sorts of changes-feeds
- retrieving the historic revision history of a certain document (as 
well as undo/rollback)
- atomic transactions
- etc.

this way, we try to keep the job of the server as simple as possible.

>
> Also, what kind of timeline are you on -- i.e., do you have
> particular milestones you want to hit?

we try to go as fast as we can, developing the remotestorage.js client 
library for it, data formats for the things we want to store on there, 
try to work out how to structure data into folders so that it's easy to 
fetch later, write apps that use it, and server implementations that are 
compliant with it, with (if you add up the volunteers) about 3 full-time 
people. that's our main constraint. :)

we have been trying to make breaking changes only twice a year, 
although we're probably going to have to disobey that self-imposed rule 
soon anyway because of a critical bug we found this week.

>
> Finally, what's the preferred venue for feedback and discussion?

currently it's a combination of 
https://github.com/remotestorage/spec/issues and 
http://remotestorage.io/community/ but we're open to changing that to 
the apps-discuss mailinglist for instance? do you think that would be 
appropriate?

> Will
> you or anyone else from remoteStorage be coming to the Berlin 
> meeting?

i live in Berlin, and given our project's tight budget, i hadn't bought 
a ticket yet. but if there is a possibility to chat about remoteStorage 
with you and/or other people there, then i'll definitely get one for 
both the meeting and the newcomer event! :)

can say roughly in which areas you would propose changing the draft?


Cheers,
Michiel