Overall status for Colony Framework (includes simple timeline)

[João Magalhães]

We're not really good with roadmaps, we are people of technology.

What I can tell is that, at the time of writing, we are definitely Alpha, but we have already have awesome value in the Colony project (not to mention production deployments).

Most things are already working as we envisioned them, and for the rest we have concrete ideas on how to make them a reality.

We have worked a lot these last couple of years to deliver on the vision of easy modularity and viral distribution, but still we have not managed to lock down a specific version.

Our main goal for the project, right now, is to go from having only one development branch, always in flux, to also having a stable branch with a well defined version and feature sets.

So, 2011 is going to be the year of 1.0.0.

We are going to determine the list of features to expect from the version and we're going to lock it down to release it on schedule.

Current global goals include: simplification, bug fixing and some feature development.

Further down the road we will revisit the Colony Distributed project, and work out the main plugins that need to be built.

We will also be working on improving support for the data layer. Introducing adapters for NoSQL engines for the first time.

We know some places we want to get to, but that doesn't make it a map.

Let me know how you feel about this!

[Markus Gattol]

With regards to storage backends in the NoSQL realm. There are two
domains that colony should cover
- graph databases (e.g. neo4j) and
- document stores (e.g. MongoDB)

Document stores will also cover the field of use cases where somebody
just needs a key/value store, graph databases allow you to store
information on the relation of entities and provide you with all kinds
of search goodness such as shortest path etc.

The reason why you want to have two kinds of data stores is so that
you can bridge them from your logic layer e.g. create a social
network, store relations and users in neo4j with a UUID to a document
(used for a particular user) in MongoDB which then takes all his data
such as photos, videos, etc. This way you get fast search in the
graph, and horizontaly scalling storage for data. That's just one
example but you get the idea.

Of course, some folks will always use/need a RDBMS but then this area
is covered already because there are tons of Python ORMs out there
already.

- MongoDB's Python driver is called PyMongo,
- neo4j's (new) Python driver (not the old one available now) will
arrive soon (before Summer 2011) afaik.

[João Magalhães]

Thanks for the input Makus,

We were just taking a look on the document base databases (like MongoDB and CouchDB) for a start.

I can really see how useful a graph based database can be for structures that are described by relations.

We'll take a look and decide how to implement the integration for both if possible.

Have you used a graph based database for a project ?

[Markus Gattol]

> Have you used a graph based database for a project ?

Yes, neo4j as it's the leading FLOSS graph database. It's a bit
annoying that the new Python driver hasn't been released yet but they
say it has been assigned high priority and will jump onto the stage
some time before summer.

With regards to MongoDB, maybe you'll find http://www.markus-gattol.name/ws/mongodb.html
useful. Also, the google groups and IRC channel are great resources,
both, for mongo and neo.