Re: Jamaica roadmap brainstorming

Some quick remarks/feedback:

- perhaps we should define terms like track,version,scenario etc.
- although the numbers are for reference only, i bet many will  
interpret them as release numbers, to avoid confusion, best re-letter  
them to their track maybe?
- is the idea to model this in trac.xaraya.com again or something else?
- do the numbers as they are now represent the order of  
*implementation*? (as opposed to releases) ?  for example 2.5 seems to  
be the first one to be done to me where as 2.1 sounds like something  
ongoing (unless we know what 'completed' means)
- functionality wise, no (additional) feedback.
- perhaps a few words on tools
- what is the development process? i can imagine it's hard for people  
to 'dive in', especially core development. Would it be possible to  
create a 'quickies list' which people can opt in to do?

marcel


On 1 mei 2009, at 10:01, [email protected] wrote:

> 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!
> _______________________________________________
> Xaraya_devel mailing list
> [email protected]
> http://xaraya.com/mailman/listinfo/xaraya_devel

-- 
Marcel van der Boom  -- http://hsdev.com/mvdb.vcf
HS-Development BV    -- http://www.hsdev.com
So! web applications -- http://make-it-so.info
Cobra Replica build  -- http://cobra.mrblog.nl

_______________________________________________
Xaraya_devel mailing list
[email protected]
http://xaraya.com/mailman/listinfo/xaraya_devel