couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Johannes <...@ntr.io>
Subject CouchDB Module System
Date Sat, 31 Dec 2011 18:34:14 GMT
Dear favorite Document-database developer community :-)
This is my first message to the mailing list, so please forgive me and
gently correct me if i am breaking any communication standards whatsoeverŠ

I am currently working on a WebDAV interface for CouchDB, that now gets
closer to its release date, somewhere in February or March and as i
approach that, I want to package everything in a proper CouchDB Module
format but the CouchDB Module system is, as i understood, in early
development or pre-development phase and needs a bit of work.

So as i work on a CouchDB Module anyways i would like to contribute to the
Module system or start kicking the work on that of.

Hence the following questions:

Who started working on such a system or would be interested in talking
about the design decisions that need to be done before actual coding can
start? 
(I know at least Jan Lehnardt expressed interest, but i can't quite
remember if he started actual work or just had plans for that.)

If there is any documentation on planning such a system, could someone
please point me to the recourses?

Lastly here is my two cents on a few topics that need to be addressed:

- We should build the best module system there is for a database or
content management system to gain back a bit of the traction we lost
during the recent plateau phase of couchdb enthusiasm

- I think "module" is the preferable term, as extension, plugin or the
like sound like second class citizens, whereas module implies, that even a
core component of the system can be made into such an instance (Any other
suggestions?)

- A CouchDB module should be packaged as a stand alone couchdb-document,
with the yet to be specified manifest beeing the json structure of the
document and the files beeing the attachment.

- Discovery, Installation, Enabling, Disabling, Module-Specific
Configuration and Distribution should be part of Futon and introduce as
little new interface concepts as possible, also the futon interface
section "configuration" may be needed to be integrated and streamlined
quite nicely

- Even if a module is not possible to completely install via this method
(e.g. It depends on a os component, that is too low level etc.) such
modules should be as tightly integrated into the system as possible and
the manual admin installation steps should be documented in a way, so that
in a normal case no place but the module system needs to be accessed

- on the top level the system should be the same for all OSes

- The work packages i see at the moment for the structure i have in mind
would be:
	
	- Module repository: A CouchDB Instance, that hosts a collection of
CouchDB Modules
	- Futon User Interface to browse available Modules in the configured
repositories, should be close to the Firefox plugin paradigms
	- Module Manifest: Descriptive CouchDoc, that references the attached
files or git repository, how files need to be fetched, packaged and what
goes where, also version 		dependencies, description, rating, Module
Category, needed system privileges (basically if you need to be a couch
admin or if you need to be root on the os), needed 		configuration, and
basic description of the configuration parameters
	- Futon User Interface to the installed modules, with options to enable,
disable, uninstall, rate and configure
	- The tools for installation/uninstallation and enabling/disabling as
well as packaging and dependency resolution

	Open questions: What existing projects could be made use of, maybe there
is something great for the general erlang world, maybe there is a project
like zero install, that 	could be made use of, maybe that is not
necessary, what are your thoughts?

I wish you all a happy new year!



Mime
View raw message