The Locker Project is awesome. It "gives people ownership over their personal data and clear control over how it's protected and shared". You can get your own Locker to run apps on your data. All in all, a project that has me excited.
The high-level concepts make a lot of sense (I particularly like the idea of Service Types!).
I found, however:
- it is very difficult to get started ("it's far from intuitive or uniform")
- it needs more structure and well-defined interfaces
- it lacks Node idioms and conventions (i.e. closer to a @visionmedia or @indexzero project style)
This is my take. It is meant to be constructive criticism, providing a concrete solution. Or rather, some guidelines.
- Establish a rich yet concise domain vocabulary
- Reorganize and restructure in order to have clear separation and well-defined interfaces
- Develop a small but working version (not everything will be implemented)
- Organized documentation
My hope is that we'll be able to incorporate these ideas into the great deal of work already present in The Locker Project itself.
- Don't start mongod process. Let users do it themselves (they might have a running instance already).
- Should be one Node application. If Python/Ruby/whatever are needed, spawn a child process. The rest is HTTP.
- Remove "Me" directory. Data belongs to the database (if there are fears of data loss, maybe use something else than MongoDB).
- Eventually use
~/.lockeras a working directory.
- Connectors and Collections shouldn't require a GUI.
- An app should require as little configuration as possible (and a piping json to stdin is a bit- unconventional).
- Apps are clearly separated from the core library. The
sample-appsdirectory is only for reference.
- Bring in h1jinx's EventEmitter2 that deals with wildcards for Service Types