Hey,
there’s a possibility that remotestorage will get some fund from mozilla (with the MOSS program).
It would be nice to put some more love in remoteStorage and that’s what I’ve thought about what could be done for next steps in rs development.
put some love on documentation (you know, all devs/hackers loves when documentation is clear and updated)
think and implement a good module structure
where I can found modules?
where do I publish it? how?
how could be modules informations be connected together? (Tag module / Bookmark module / Photo module, it would be cool to have these informations linked someway, e.g. a photo linked to urls and to some tags…)
in general rethink the idea behind modules (how data they manage are declared?)
create an environment to quickly create/test/publish them.
implement encryption of data (with a flag) in modules (I think this is mandatory, but probably needs an update of spec?)
obviously, feel free to ask, modify, add and remove.
That’s a good list! I can’t think of anything more important after the 1.0 release.
As the MOSS application has to be for a specific topic/task, I would propose to go with the modules. There’s just a lot to do, as you outlined, and yet it’s all kind of interconnected and regards one specific topic. Maybe we can define the exact goals a bit better, based up on this list.
1. Module publishing/registry
I guess it’s easiest to just go with a convention for npm module names (and/or Git repo names) for this. We could also add a wiki page with static links to known modules, too. Why re-invent the wheel and build that stuff ourselves, when we can just use the most popular package registry today. (So maybe not ideal for a grant goal, as it should be easy and quick to do before.)
2. Module concept/layout/scopes/linked-data
I think this is the big one we have to tackle. I can see multiple topics coming out of it:
Use Linked Data, JSON-LD etc. correctly, decouple schemas from module code, and allow linking between schemas (as per JSON-LD and JSON-Schema specs)
Generate docs from/for schemas for developers to quickly see what properties they can use and how
Decide what to publish in the location of the JSON-LD @context URL and implement automation for it
Rethink the way modules are actually used and defined (e.g. do we even need custom module code for a module that only stores JSON objects in subdirectories, or can that be done via a standard API that does lists/subdirs in addition to schemas/types)
3. Module CLI
Correct me if I’m wrong, but this sounds like the idea for a CLI that lets one create a rs.js module from the command line, including its npm package info, dependencies, a test setup and so on. That would be awesome!
As this only makes sense once we’ve solved topic no. 2, I think this probably also makes sense to do outside of the grant goals.
Focusing on modules makes a lot of sense. Having a general way how to encrypt the data is obviously great and I especially like the idea of a CLI for generating new modules.
Everyone, please keep in mind: the deadline for the application is this Sunday, so we need to decide on the specific goals asap, otherwise we don’t have time to also write the actual application!
I made some comments on what I think could be among those goals. Please keep that conversation going. Thanks!
Please describe what you would use the funds for - what you are going to build, hack or fix. Also, explains how it furthers our mission, perhaps tying your activities to items in the Manifesto - The Mozilla Manifesto.
I think we can easily tie the library to the manifesto more generally (I mean, RS hits almost all points), but we need to explain exactly what we’re going to develop with the funds in any case.
Ok, let’s go on with modules, as you well outlined they are the next big thing to make rs a serious library.
decoupling schema from modules core is a good point, from here we can also have that CLI you mentioned to produce real code modules (I’m a fan of source2source and source generation) or the module could be only the JSON-LD itself (if the operations on data modules will be standardized as you outlined in your last point).
the real big point here I think, is how to manage connection between different modules (eg. a Bookmark with a Tag or a Photo with a Bookmark and some Tags; could be very cool to have the possibility to connect each data to another)
This point and the first one are strictly tied with principle #6 of mozilla manifesto (but in general RS is based on open protocols like Oauth and HTTP so in general rs is tied with #6).
modules doc generation is a must, we have to see how to do it, how to publish it, where to publish it to make these information easily accessible.
about the submission:
I think that principle #4 (security and privacy) is also one of the main goal of remotestorage, and #5 (ability shape the Internet) fits great because storing your data somewhere else than on big player means also to not passively accept it and create a better Internet environment that remain open and accessible (one bit at time) as written also in #2 #8(community based process, trust, promote partecipation) and #7 (free and open source) is what are we doing here in the forum, in IRC and via github: sharing problems and finding solutions.
I was thinking about how to outline and submit this, and wondered if creating one or two tracking issues for these topics in the modules repo is a good way to approach it. Sooner or later we need to properly discuss and define it on GitHub anyway, and if we put it there now, we could give the MOSS folks a link to the issue(s) in the application, so they can get a better picture. What do you think?
@les let me know if you need any help with the proposal. May it be wording, proofreading or anything else. I can also help with creating those tracking issues @raucao suggested.
I’m on the road during the day today, but I have some time early evening.
Maybe you can post here what you already have and we can go from there?
@galfert The idea was actually to create the issues first, then discuss and edit them until they can be copied almost 1:1 to the proposal or summarized and linked from there. But that was just my idea, of course. Any method that gets us to a final application by tomorrow night is valid!
here in the forum, in IRC and via github: sharing problems and finding solutions.