Re: [PROPOSAL] lifecycle release

Peter,

could you either retract your vetoes issued as part of this thread or 
reply to my last e-mail concerning those vetoes (or do both, of course)? 
Leaving this "hanging in mid-air" seems like a bad idea :D

cheers!

- Leo

Leo Simons wrote:
> Peter Donald wrote:
> 
>>> we have discussed moving materials which do not belong at the same
>>> level as avalon-framework into the avalon CVS module before.
>>
>>
>> And yet it hasn't happened.
> 
> 
> twist those words around a bit:
> 
> and it hasn't happened yet
> 
> :D
> 
>>> Can you motivate why you think that is not a good idea?
>>
>>
>> Because it is not common to all containers or development strategies.
> 
> 
> So you are saying that materials that go into the avalon CVS module 
> should be common to all containers and development strategies. Why?
> 
> Berin wrote:
> 
>> CLARIFICATION:
>>
>> No one has proposed making them part of FRAMEWORK.  It is a question
>> of which repository to move to.
>>
>> It is a question of whether we want to make the "avalon" CVS
>> repository support a framework directory structure and an extension
>> directory structure.
> 
> 
> to make that even more clear (well maybe), the idea is something like
> 
> ssh cvs.apache.org
> umask 002
> cd /home/cvs/avalon
> cp -Rfp * framework
> cp -Rfp ../avalon-sandbox/lifecycle .
> exit
> cd ~/cvs/avalon
> cvs rm -Rf *
> cvs commit -m 'moving into framework/ subdirectory'
> cvs up -P -d
> 
> this was talked about before; the idea back then was to move everything
> that is not generic utility code (ie meta, containerkit, similar stuff,
> but not IO or CLI) into the main avalon cvs (when ready to move out of 
> the sandbox). You would end up with
> 
> /home/cvs/avalon
>     README.txt
>     LICENSE.txt
>     framework/
>     lifecycle/
>     meta/
>     interceptor/
>     fortress/
>     ...
> 
> Clearly, neither a meta model nor lifecycle extensions nor interceptors 
> nor fortress would be common across containers (anytime soon). Its just 
> about organisation.
> 
>> The Marker interfaces will probably be deprecated post fortress
>> release. The *Selector interfaces can also be considered for
>> deprecation. In the future I can see the release() methods also being
>> deprecated.
> 
> 
> that's quite another (ancient ;) discussion.
> 
>>>>> * the release of the avalon-lifecycle package shall be considered 
>>>>> as an "optional" extension to the framework contracts
>>>>
>>>>
>>>> -1
>>>>
>>>> It is the same approach that has been done before and failed and
>>>> can't cleanly produce some aspects like delayed activation,
>>>> passivation, persistence, transaction demarcation, bifuricating
>>>> interception etc.
>>>
>>>
>>> Taking your -1 as a veto rather than an opinion, you should provide
>>> a viable alternative for it to be valid, which AFAIK you haven't
>>> done.
>>
>>
>> Several times before - you even committed one of my emails to CVS.
>>
>> Interceptors will solve all these problems (and many more besides).
>> Go to Rickard Öbergs blog for a good description. Alternatively go
>> through the links I have provided in the past. Several good articles
>> are available in msdn these days aswell.
> 
> 
> Your -1 applies to "the release of the avalon-lifecycle package shall be 
> considered as an "optional" extension to the framework contracts", 
> doesn't it? Saying "avalon-lifecycle (c/sh)ould be implemented 
> differently using interceptors" is a different story alltogether, innit?
> 
> I am all for finding the best implementation. In the meantime, fortress 
> doesn't have an interceptor-based architecture, it sounds like a lot of 
> work to put it in now, and I think it needs a release.
> 
>>> Also, could you please provide more specific information about why
>>> the approach in the lifecycle package fails, perhaps with a code
>>> example?
>>
>>
>> Perhaps you could show me how it succeeds.
> 
> 
> sure. Fortress provides support for instrumentation management by using 
> the lifecycle and instrument-manager packages. This is, atm, my usecase 
> for the lifecycle package, and it succeeds there.
> 
>> We have tried it in the
>> past and it led to spagetti code.
> 
> 
> you think the way fortress does instrumentation is "spaghetti-like"? I 
> sorta like it. Its the only time I've tried using lifecycle extensions, 
> IIRC.
> 
>>> I would also like to point out that IMHO you're "throwing a veto"
>>> rather lightly. I think it makes the discussion more productive if
>>> you take some more effort to back a -1 before issueing it.
>>
>>
>> Get over. I have spent hours upon hours explaining this and wrote up
>> several long emails and documents explaining this in the past. I have
>> given oodles and oodles of links to both java and dot.net based
>> approaches. What is it you find lacking in my previous explanations?
> 
> 
> - you didn't mention them when vetoeing;
> - it apperas like you haven't bothered to fully digest what the proposal 
> was about (see above), and what context it was issued in;
> 
> - You've pointed to lots of alternative approaches which look pretty 
> promising, but I can remember nor find in the archives any example as to 
> why the lifecycle package is so bad it should be dismissed as a "hack". 
> Just the fact that something could be implemented differently and is in 
> other architectures is not a good enough reason to do it IMO, if the 
> other way happens to make sense and accomplish its goals. In fact, I 
> have code working just fine in front of my face (fortress) which uses it.
> 
> Pete, I think this is not something where we should just say "get over 
> it". When we had all the flame fests in august/september, that started 
> with some "lightly thrown" vetoes, too.
> 
> cheers,
> 
> - Leo