cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Savory <and...@luminas.co.uk>
Subject Re: [RT] Rules for adding blocks and functionality?
Date Sun, 23 Oct 2005 19:48:28 GMT
Hi,

On 23 Oct 2005, at 19:20, Daniel Fagerstrom wrote:

> Just because of its importance, you agree that it is important  
> don't you ;) we should follow our usual and well proven development  
> patterns which involves community involvement.

FWIW, Sylvain showed quite a few people an example of this  
functionality at the hackathon, and I think we all said "ooh, please  
commit it ASAP!" at the time.

So there was some community involvement (though I know there's no  
substitute for doing it on the list, where the whole community can see).

> And what is much worse: we never remove anything.
>
> So, taking DB-handling as an example: in the databases block we  
> have ESQL, modular DB modules and actions and the SQLTransformer,  
> three different approaches to do the same thing, all of them  
> considered to be obsolete. Furthermore we have the OJB block that  
> is still another and maybe better way of handling DBs, and now we  
> have your new stuff.

... which makes me think that actually we should have an article  
explaining the differences between them all, and why you might use  
each block in a given context.

> * New kind of functionality should (in general) go to new blocks.
> * New blocks should go through some incubation process, starting in  
> the whiteboard and needing a small community and a vote to get out  
> from there.

Agreed to both of these.

> * We really need to get rid of obsolete stuff. Must really every  
> single block go to 2.2? Are there some oneman shows that better  
> could be returned to their creator and driven on source forge or  
> Cocoon-dev?

Hmm. I'm not convinced of this. The problem is that we can't  
anticipate which blocks our users want, they may have perfectly valid  
reasons for using e.g. the SQL Transformer (even if we wished they  
didn't). I don't know how we can remove historical functionality  
without upsetting -someone-. I'm not sure how this can be solved ...


Andrew.

--
Andrew Savory, Managing Director, Luminas Limited
Tel: +44 (0)870 741 6658  Fax: +44 (0)700 598 1135
Web: http://www.luminas.co.uk/
Orixo alliance: http://www.orixo.com/


Mime
View raw message