my plan with remotestorage is more or less the following:
get the support for version -02 of the remotestorage spec more stable.
then add GoogleDrive and Dropbox support to the library.
then build native versions for Firefox, Chrome, PhoneGap, Firefox OS, etcetera.
in the process, we obviously continuously work on improving documentation, fixing bugs as soon as we find them, etcetera, but i thought it would be instructive to define those three steps.
in particular, it can be tempting to work on everything at once, and i think it’s more productive to define three “phases” this way.
I think it’s completely missing the most important step: cleaning up the library, fixing all bugs and wrong/weird behaviour, improving test coverage, improving onboarding experience, etc.
It is also missing the second most important step: fixing the module situation.
Could we stop making long-term plans all the time and just focus on the tasks at hand? These are old and known, and throwing in completely new goals every 2 months is contra-productive in my opinion.
hi @raucao yeah, you’re right that the most important part is fixing all bugs, and improving the onboarding experience, but that’s also what i meant with the work we do continuously. so we mean the same thing. also, i should clarify that when i say -02 support i don’t only mean fixing all wireclient bugs, but also all sync and versioning bugs, since that’s something we only started doing now for the ETag-based specs.
the modules situation is not part of remoteStorage.js core, it’s a separate thing. doesn’t make it less important of course! but that’s why it wasn’t on the list here. in particular, i want to do a lot of work on the contacts module, and on common patterrns for how modules handle partially synced trees and chronological indexes, but none of that is part of remoteStorage.js core, i see that more as part of developing the various applications (so litewrite develops the documents module, an image gallery app developes the pictures modules, etcetera).
It’s maybe not in the core repo, but of course it belongs to core to fix the whole situation of outdated modules, no tests, no good documentation, and no good base modules people can use both for apps and as reference for creating new modules.
It also completely belongs in core work to solve how modules can share behaviour like e.g. indexing/search.
These problems are far more important for app developers today than a hypothetical browser extension.
oh right, yeah, there’s cleaning up the modules repo which we still didn’t do properly. ok, so once we got the -02 compatibility working well (point 1), let’s first do a big cleanup of documentation, test coverage, and the modules repo, and insert that as “point 1 1/2”, before we go on to points 2 and 3.
Sorry I’m responding to an old post but I think this is the wrong way to look at it. It is a much more powerful thing to do to support people where they are currently at - i.e. using drive and dropbox and then get them to see that they are just dumb storage devices that can be swapped out. Then rely on people to give up on them and sign up for some esoteric or self-hosted solution just to get their toes in the water. Having drive and dropbox supported turns this project from a geek lovechild to something with instant mass appeal without in any way detracting from its core ability to give people alternatives to mainstream providers.
no. the chicken-and-egg problem which you are referring to, of users having remoteStorage account on the one hand and app developers using remotestorage.js on the other, is resolved as soon as we finish and publish its GoogleDrive support. then one single app can be successful, without relying on other available apps building up critical mass first.
but that’s why it wasn’t on the list here. in particular, i want to do a lot of work on the contacts module, and on common patterrns for how modules handle partially synced trees and chronological indexes, but none of that is part of remoteStorage.js core, i see that more as part of developing the various applications (so litewrite develops the documents module, an image gallery app developes the pictures modules, etcetera).