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
|