Jamaica roadmap brainstorming

The following is a first cut of ideas for a Jamaica roadmap. These 
roadmap ideas focus on "tracks", rather than versions. The track idea 
lets us look at different developent areas simultaneously, inasmuch as 
each track addresses one or more areas fairly distinct from the others. 
This means that releases can in theory be drawn from any track as it 
reaches its milestones. The numbers in each track may be fleshed out to 
actual releases at some point, but below they are just for reference, 
and in particular don^t represent any foreseen order of releases.

Track A

2.0
Work will be based on the current core.jamaica repository as described 
in previous emails. In addition to the usual bugfixes that accumulate, 
there will be a review and cleanup of the code in the core modules, as 
well as templates if time permits.
We should also arrive at a reasonable coverage of the API through units 
tests, which will make faclitate fixing things going forward. Some of 
the more globally useful dataproperties in modules can also be moved to 
the core modules (for the time being, see 2.5 below). Core Module 
overviews need to be rewriten.

2.1
In this phase the BL2 compiler will reach a "completed" state. A 
mechanism will be implemented for installing custom tags. MLS support 
for attributes may or may not be implemented.

2.2
Integration of the core.unstable.tableddl scenario. The focus here is on 
making it possible to manage the data tables via the UI. The code for 
tables in the core modules and the core is removed, and XML files are 
used instead.

2.3 Integration of the core.unstable.newblocks scenario. This reduces 
the number of blocks tables. Convert blocks to an object tree akin to 
the dataproperties in DD. Integration of the core.jamaica.blockmasks 
scenario. This introduces anonymous masks for blocks. Other enhancements 
are still to be discussed.

2.4 Privileges rework, we need a clearer concept of how security checks 
are applied in different situations. The privileges UI also needs to 
become simpler. Look at the data manager concept and decide if/how to 
implement this in some form.

2.5 Finalize and implement a file structure based on the proposals 
already on hand. This should make it possible to centralize definitions 
for things such as dataproperties or libarary plugins.

2.6 Creation of a component manager (initially probably as a module) 
based on propel or something similar. The manager should make it 
possible to update sites with the latest release automatically. It 
should also manage module installs in an easy and automatic manner, a la 
joomla. For this, a completed file structure design is a requirement for 
this work.


Track B

3.0 This track may be based on developent work in the 
core.jamaica.singleds scenario (not yet in the official repositories). 
It scales back dynamicdata to support only certain types of data stores, 
and in particular only one store per object. Data sources are all 
defined in the objects, and each automatically  assembles its dataquery 
when it is created. In this way the querying of the database becomes 
transparent to the developer. Specific features include automatic 
one-to-one multitable support and one-to-many support. The subitems 
property from my math module repository can also be added (to the base 
module?).
In this development track we also need to review the status of Creole, 
whether or not to replace it and with what. This is not because Creole 
considers itself dead. The main question is whether Creole can support 
the new dd concept of datastorage.


Track C

4.0 This track will focus on client side enhancements to the UI, in 
first order AJAX and one or more JS frameworks. Support for both XML and 
JSON for AJAX is likely to be needed, but we could do with XML for 
starters. A good JS-PHP library would be helpful, since we probably 
don't want to write one ourselves. A major question is therefore to what 
degree we want to expose one or more javascript APIs in the codebase, 
or, seen from a different angle: do future Xaraya core or module 
developers need to know javascript in addition to the already long list 
of skills needed?

Additions and ideas welcome!