Developing the Bright Content Store
Eric Larson
has become a bit clearer. Currently the store does use a database,
which was arguably to reduce requirements, but in reality the
reasoning is that we wanted to work in documents. This means that the
storage facilities are based on the idea of a document store instead
of a data store. This subtle, yet critical, difference is similar to
the difference between using XML for publishing over using it for
configuration. In this case, we use it in the document based form and
storing it as such.
In thinking about document stores it was brought up that Java has an
actual specification for creating a document store called JCR 170. I
have barely read this specification, but I have used jackrabbit
(second hand) and realize the difference between it and a traditional
database. In Jackrabbit, there is the ability to version and index
binary formats such as word documents though plugins. I'm not going to
say that I want to do this in Bright Content, but the concept of a
document store seems to suggest that this idea is important.
With this in mind I propose we consider a design document that
outlines the purpose of the store and how it might be considered a JCR
170 or WSGI for Python Content Management systems. The BC store can be
an implementation of this document. The basic components that seem
essential so far are:
- Adding indexes to the store for different types as defined by the mime types
- Versioning of documents
- Filtering for business logic
At this point the one detail above I think is semi-non-important is
the versioning as Amplee currently can use an SVN store that is
essentially just a file system with svn ci added to docs. This seems
to be enough in my opinion, but who knows. For example, in a recent
project, we used consecutive entries with the same
atom:link[@rel='alternate'] as the identifier to specify it was the
same document, with different revisions.
What is definitely needed is the way to add indexes and filtering. The
filtering pieces have been done so far using basic extension of the
store object via __getattr__ and an internal object. The indexing has
yet to be solved generically and still requires knowledge of Amplee.
This is ok in that it is minimal, but still it would be nice to avoid
the visible dependency.
So what do folks think? Is a WSGI for a Python document stores a decent idea?
Eric