Version 3.17

This version should be published before the end of March and will finish all the things that are work in progress. It will include:

• the refactoring necessary to introduce persistant sessions,
• the shrinking of web/views: everything that does not deserve its own cube (like sioc, embed, geocoding, etc) will go into a cube named legacyui (this will open the door to squareui),
• stop serving pages with "content-type: application/xhtml",
• handling postgresql schemas (will require a new version of logilab.database),
• a new logo.

Squareui

Once the cube legacyui extracted (in version 3.17), it will be possible to move forward swiftly with squareui. Due to its other duties, one can not expect the core CW team to develop squareui. People interested will be in charge and ideally the squareui cube could be released when cubicweb 3.17 will be published.

Cleaning up the backlog

The lead CW developers will spend about 20% of their time cleaning up the ticket backlog at the forge (900 open tickets and 50 in progress !)

The first step will be to reduce the number of tickets "in progress", then to organize the open tickets and merge the duplicates.

Version 3.18

This version is due at the end of may 2013. It will include:

• persisting sessions,
• WSGI,
• RESTfulness: support for HTTP verbs PUT / DELETE, enforcement of the semantics of GET / POST (may be difficult to maintain backward-compatibility)

Mid-term goals

The mid-term goals are:

• possibility to add new base types (Array, HStore, Geometry, TSVector, etc.) that would use extensions from the SQL backend

• FROM clause in rql queries

• websockets

• defining attribute on relations and defining "virtual" relations or rules:

class Contribution(EntityType):
author = SubjectRelation('Person', cardinality='1*', inlined=True)
book = SubjectRelation('Book', cardinality='1*', inlined=True)
role = SubjectRelation('Role', cardinality='1*', inlined=True)preface_writer = VirtualRelation('C is Contribution, C author S, C book O, '
'C role R, R name "preface writer"')

And:

Any P WHERE B is Book, P preface_writer B

Will we need a materialized view in the database, a standard relation maintained by hooks, rewrite the RQL on-the-fly ? Time will tell.

• cards with logic (mustache js templates for example)

• coffeescript ? brython ? javascript ? prototype something with CubicDB + WebService that outputs json + user interface in full javascript

• package separately Cubic(Web)DB et CubicWeb ?

• think about the overall architecture (using WSGI, persistent sessions, etc.), and find solutions that fit a distributed architecture (look at paste.deploy, circus, etc.)

• clean up the javascript en web/data/*.js

• configurable metadata, managing the size of the entities table

• more SPARQL

• namespaces for the data models of the cubes

As already said on the mailing list, other developers and contributors are more than welcome to share their own goals in order to define a roadmap that best fits everyone's needs.

Logilab's next roadmap meeting will be held at the beginning of April 2013.