cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <...@outerthought.org>
Subject Re: [Vote] Controller/Sitemap integration
Date Fri, 18 Jul 2003 08:57:43 GMT


Stephan Michels wrote:
> On Thu, 17 Jul 2003, Joerg Heinicke wrote:
> 
> 
>>Reinhard Pötz wrote:
>>
>>>As I have been confused by all those suggestions you can find a summary
>>>here:
>>>http://wiki.cocoondev.org/Wiki.jsp?page=FlowSitemapIntegration
>>
>>Cool summary, really helps a lot. And here the cool voting matrix :)
>>
>>
>>     |   A   |   B   |   C   |   D   |   E   |
>>----|-------|-------|-------|-------|-------|
>>     |       |       |       |       |       |
>>V1  |  -1   |  +0   |  +0   |  +.5  |  +1   |
>>     |       |       |       |       |       |
>>V2  |  +1   |  -1   |  -0   |  +.5  |  -1   |
>>     |       |       |       |       |       |
>>V3  |  ??   |  +.5  |  -1   |   \   |   \   |
>>     |       |       |       |       |       |
>>V4  |   \   |  -1   |  -0   |   \   |   \   |
>>     |       |       |       |       |       |
>>V5  |   \   |  +1   |  +.5  |   \   |   \   |
>>     |       |       |       |       |       |
>>V6  |   \   |   \   |  -1   |   \   |   \   |
>>     |       |       |       |       |       |
>>V7  |   \   |   \   |  +1   |   \   |   \   |
>>     |       |       |       |       |       |
>>----|-------|-------|-------|-------|-------|
>>
>>
>>What is the difference between A V1 and A V2? Only the <map:flows/>? And
>>what does it mean?
>>
>>B V5 was missing. From Marc's answer I guess he meant this, but chooses V1.
> 
> 
> Don't you think that this makes the voting really difficult ;-)
> 

I think the roundup and visualization really helps
it's just that the voting _is_ complex since there have been a 
lot of arguments on the table

the alternative would be to go into the meta-level of discussing 
which arguments are valid and which not (hardly easier since a 
lot of this is personal perception and not to be black/white or 
true/false)

> A: V1
> B: V2
> C: V1 with flow instead of type
> 
> D: V2
> E: V2
> 
> BTW, I think it too early to vote on this. If I must decide now,
> all will be carved in stone. I think we should leave A-C as it is
> for 2.1. And postpone the discussion to the post-2.1-era.
> For my part, I must have first two implementations to find
> more generalized contract, which we don't have at this point.
> 
> So my vote would like:
> Should we postpone the generalisation to the post-2.1-era,
> and hazard with the consequences, that we maybe change the
> sitemap syntax of a released version of Cocoon?
> 
> +1
> 

I partially agree:
- refactoring and continuous design is the reality of this world: 
pretending to 'carve in stone' is close to telling lies
- the stress on getting the abstract level right without the 
insight of enough detail in the multiple implementations feels 
unnatural (given that refactoring has become so easy)

But I also see the other side of things:
- refactoring and change can be a give to those that know the 
internals and live by the laws of cvs-head, the same level of 
flexibility eagerness might not be found in settings where 
upgrading to the latest stable cocoon release is something that 
is scheduled at best once a year
- it might be a challenge to abstract things upfront, but brave 
man like us do not fear challenges ;-)


So maybe the consensus getting us into beta stage can maybe be 
reached by splitting up
- vote on A-C now, carve in 'sand-stone': these are related to 
non-coding end-users of flow, transition from one to the other 
costs more

- decide on D-E _for_ now, carve in 'yoghurt': this is related to 
developer decisions, dependent developers would probably less 
mind if changes occur, their refactoring IDE's would help them 
out a great deal...

in both cases we (must realize that we) are making a best 
estimate on what we know now, that is just how life is...

the remaining argument to actually decide here and now is it gets 
us out of the catch-22: it enables more nicely the alternative 
implementations that will get us the deeper insight we're missing 
to date


what do others think?
(I might be missing the complete point of release management 
here, I don't mind if someone points that out to me)

> 
> Stephan.
> 

-marc=
-- 
Marc Portier                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at              http://radio.weblogs.com/0116284/
mpo@outerthought.org                              mpo@apache.org


Mime
View raw message