Afaik, remotestorage.js 0.8.3 already supports this spec, and it should be possible to get all existing apps that are being actively maintained on to 0.8.3. Then, on 10 December, it will be safe for all servers to start offering only remotestorage-02.
After the last servers out there have moved away from rww#simple, remotestorage.js can then be simplified to only support -00, -01, and -02, and we can start dropping support for rww#simple servers.
as you can see, no new features were introduced. the main changes compared to -01 are to switch to the rfc-version of WebFinger, correct the 412/304 response code bug, and the text is a lot longer now because i added example wire transcripts as requested by several people, and a Computer Science style discussion of distributed versioning as suggested by Mark Nottingham at our Bar BoF this summer at the IETF meeting.
i’m also not planning any new features for version -03, so things should be getting pretty stable now, we can start focussing on the other points of the remotestorage.js roadmap.
No matter what you say, we still need the proposed features from several open discussions on GitHub. If you don’t listen to users and providers, we’ll need to implement them with a forked spec. I don’t see why you find it necessary to ignore that, and I urge you to think about your stance on the matter and listen to people with use cases.
@raucao thanks for you comment, i understand you’re disappointed that we’re not working on your proposal for adding file size support, despite the fact that it’s a very well-sounding and defendable proposal.
i agree your proposal sounds nice, but fact is, we need to choose something to work on, and then focus on that in a coordinated way. although it might be fun and creative to fork into two or more uncoordinated projects, everybody adding their favorite feature in their own way, and adding ever more bells and whistles, but that’s not in the user’s interest.
we now have the basics working, that’s already a great achievement. we should now focus on stable servers, stable spec, stable core library, so that we can invest our time into building apps&modules on top of it. that is where we can have an impact on the value to end-users.
i have proposed three phases for what we need to work on Roadmap, three phases and everybody can make suggestions to what needs to be added (as you indeed did), but we can only achieve a stable environment for application developers if we all focus on the same basic feature set.
we are a small team and we already have way too many different things to focus on; if we were to add file size support to the list of tasks then it would become even more impossible, sorry!
You’re completely turning reality on its head, and you’re doing it on purpose. I will take some time to comment on this, but I must say defending against elaborate strawmen arguments is not a productive use of our time.
the feature we discussed in Unhošť was to change the directory listing format to include not only the ETag for each item, but also the Content-Type and the Content-Length, and to also make this information available via HEAD requests.
i’m not saying this would be a bad or useless feature per se, i’m just saying it’s not a priority. we still have time until 10 December to decide about this, but if we add it in the spec then we also need to add it in Roadmap, three phases - do i understand correctly that that is what you are proposing?
@silverbucket@galfert and others, do you also agree with @raucao on this topic? if it’s really that important to you as app developers then we can change it, but it would go at the cost of other work. at which phase in the roadmap would you add it? before or after phase 2? maybe we can do a conf call about this on wednesday.
ok, i created an alternative version ‘-02a’ which won’t go to the IETF at this point, but with which you can play around. it has a different folder description format, and also mentions HEAD requests. i’ll accept pull requests to add support for it to remotestorage.js, provided the new functions you add to the base client that use this also have fallback behavior for existing servers. https://github.com/remotestorage/spec/commits/master
in any case i think it would be good to have a meeting on wednesday, let’s say 4pm at the rebel base and/or via WebRTC? i’ll open a separate thread in the ‘events’ category
