followup (offlist)

[Stephen McConnell <mc...@apache.org>]

Geoff:

Just wanted to followup with you on the subject of 
Merlin/Cocoon/Avalon/Blocks/etc.

A few weeks ago there were several users@avalon people pushing for 
greater collaboration with Cocoon on the Merlin/Cocoon block question. 
That was the stimulus for taking a more proactive role in pushing 
information out to the Cocoon list about what Avalon is doing.  On the 
otherhand I'm kind of getting a sustained message "go away while we sort 
this out ourselves" - and I don't want to appear to be pushing something 
that isn't wanted.

I was wondering if you could give me some "private" feedback. In you 
opinion should we be working towards Avalon/Cocoon collaboration or 
should we simply come back in a year or eighteen months to see what is 
happening?  If its collaboration then some concrete things need to be 
considered on the Avalon side and communication channels need to be 
established.  If not - there are migration issues related to 
ECM/Fortress that can take a back seat in favour of other priorities.  
In the overall Avalon picture this has to be addressed as we move 
towards a single Avalon solution - in the shorterm - the Cocoon/Avalon 
relationship feels kind of mixed.

Any thoughts that would maybe give me a clue on direction?

Stephen.

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org

Re: followup (offlist)

[Stephen McConnell <mc...@apache.org>]

Well that was intended as an offlist message.
Now that its on-list - maybe its a good idea to get some broader feedback?
Stephen.


Stephen McConnell wrote:

>
> Geoff:
>
> Just wanted to followup with you on the subject of 
> Merlin/Cocoon/Avalon/Blocks/etc.
>
> A few weeks ago there were several users@avalon people pushing for 
> greater collaboration with Cocoon on the Merlin/Cocoon block question. 
> That was the stimulus for taking a more proactive role in pushing 
> information out to the Cocoon list about what Avalon is doing.  On the 
> otherhand I'm kind of getting a sustained message "go away while we 
> sort this out ourselves" - and I don't want to appear to be pushing 
> something that isn't wanted.
>
> I was wondering if you could give me some "private" feedback. In you 
> opinion should we be working towards Avalon/Cocoon collaboration or 
> should we simply come back in a year or eighteen months to see what is 
> happening?  If its collaboration then some concrete things need to be 
> considered on the Avalon side and communication channels need to be 
> established.  If not - there are migration issues related to 
> ECM/Fortress that can take a back seat in favour of other priorities.  
> In the overall Avalon picture this has to be addressed as we move 
> towards a single Avalon solution - in the shorterm - the Cocoon/Avalon 
> relationship feels kind of mixed.
>
> Any thoughts that would maybe give me a clue on direction?
>
> Stephen.
>

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org

Re: followup

[Stephen McConnell <mc...@apache.org>]

Stefano Mazzocchi wrote:

>>   If its collaboration then some concrete things need to be 
>> considered on the Avalon side and communication channels need to be 
>> established.  If not - there are migration issues related to 
>> ECM/Fortress that can take a back seat in favour of other priorities.
>
>
> ? you are mixing concerns. migrating ECM to Fortress has nothing to do 
> with block support. 


Actually it has. There is Avalon and Avalon is supporting the products 
your using.

Fortress/ECM represent a product family within which there are specific 
semantic assumptions.  Those assumptions need to be drawn out to a more 
formal specification (and possibly supporting object model) as part of 
the Avalon development.  The Phoenix/Merlin style of component 
management represents a different set of assumptions.  The 
Fortress/Merlin development has brought that a lot closer, but the end 
game is the single product that incorporates cleanly and consitently 
these differences.  Reaching the common solution is the migration 
process I'm talking about.  This process is on our roadmap along with a 
bunch of other topics - hense my note concerning priorities.


>
>> In the overall Avalon picture this has to be addressed as we move 
>> towards a single Avalon solution - in the shorterm - the 
>> Cocoon/Avalon relationship feels kind of mixed.
>
>
> Cocoon is using the Avalon Framework, ECM and some Excalibur 
> components (some of which are maintained entirely by cocoon 
> committers). Nothing else.
>
> Should we use more? if it makes sense, yes.
>
> Why should we spend months in trying to come up with a solution that 
> makes both Avalon and Cocoon happy for blocks instead of just 
> implementing a design that we already spent almost a year designing? 


Lots of reasons, not least are the broadening of the pool of expertise 
and the potential to leverage experience gained.

Stephen.

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org

Re: followup (offlist)

[Gianugo Rabellino <gi...@apache.org>]

Bertrand Delacretaz wrote:
> Le Jeudi, 2 oct 2003, à 14:28 Europe/Zurich, Berin Loritsch a écrit
> 
>> ...For instance, if you changed BLOCK-INF to COCOON-INF, then it is 
>> very clear
>> that the Cocoon solution is proprietary to Cocoon, and noone should 
>> expect
>> a Cocoon block to function the same way in a Merlin/Phoenix environment.
> 
> 
> Sorry, I overlooked this when saying that I basically agree with Stefano 
> on going our own way for blocks at this time.
> 
> I'm +1 on changing the BLOCK-INF name to COCOON-INF or whatever makes 
> sense and does not cause conflicts.

+1 here too.

Ciao,

-- 
Gianugo Rabellino
Pro-netics s.r.l. -  http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
     (Now blogging at: http://blogs.cocoondev.org/gianugo/)

Re: followup (offlist)

[Bertrand Delacretaz <bd...@apache.org>]

Le Jeudi, 2 oct 2003, à 14:28 Europe/Zurich, Berin Loritsch a écrit

> ...For instance, if you changed BLOCK-INF to COCOON-INF, then it is 
> very clear
> that the Cocoon solution is proprietary to Cocoon, and noone should 
> expect
> a Cocoon block to function the same way in a Merlin/Phoenix 
> environment.

Sorry, I overlooked this when saying that I basically agree with 
Stefano on going our own way for blocks at this time.

I'm +1 on changing the BLOCK-INF name to COCOON-INF or whatever makes 
sense and does not cause conflicts.

> ..the BLOCK-INF directory is a net liability for
> both of us--and blindly dismissing that would be a bad thing IMNSHO...

I was blind, but now I see (a little bit) - thanks!

-Bertrand

Re: followup (offlist)

[Berin Loritsch <bl...@apache.org>]

Bertrand Delacretaz wrote:

> Le Jeudi, 2 oct 2003, à 11:56 Europe/Zurich, Stefano Mazzocchi a écrit :
> 
>> ...Why should we spend months in trying to come up with a solution 
>> that makes both Avalon and Cocoon happy for blocks instead of just 
>> implementing a design that we already spent almost a year designing? 
>> for what?
> 
> 
>> ...
>> Anyway, the above is *my* personal vision. I would like to hear what 
>> others think as well.
> 
> 
> I agree - with all the recent activity on blocks design, it would be a 
> bad time to try to synchronize the design or implementation with another 
> project.
> 
> Once implemented, relevant parts of the Cocoon Blocks can be 
> incorporated into Avalon if it makes sense, as it already happened with 
> some components.

Here is the deal, though.

Certain aspects such as the BLOCK-INF/ directory structure are already in
use with other systems.  As such, your blocks would create some conflict
with folks who think they can use the same block in both places.

If you really don't want help with your blocks proposal, fine.  We aren't
going to force our hand on you--but as long as you are being proprietary
and are not interested in collaboration at this time, try to use something
that is not likely to conflict with other projects.

For instance, if you changed BLOCK-INF to COCOON-INF, then it is very clear
that the Cocoon solution is proprietary to Cocoon, and noone should expect
a Cocoon block to function the same way in a Merlin/Phoenix environment.

If you can do that much, we will leave you alone and let you develop in
peace.  The thing is, using the BLOCK-INF directory is a net liability for
both of us--and blindly dismissing that would be a bad thing IMNSHO.


-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin

Re: followup (offlist)

[Bertrand Delacretaz <bd...@apache.org>]

Le Jeudi, 2 oct 2003, à 11:56 Europe/Zurich, Stefano Mazzocchi a écrit :

> ...Why should we spend months in trying to come up with a solution 
> that makes both Avalon and Cocoon happy for blocks instead of just 
> implementing a design that we already spent almost a year designing? 
> for what?

> ...
> Anyway, the above is *my* personal vision. I would like to hear what 
> others think as well.

I agree - with all the recent activity on blocks design, it would be a 
bad time to try to synchronize the design or implementation with 
another project.

Once implemented, relevant parts of the Cocoon Blocks can be 
incorporated into Avalon if it makes sense, as it already happened with 
some components.

-Bertrand

Re: followup (offlist)

[Stefano Mazzocchi <st...@apache.org>]

Talking about 'upps'...

On Thursday, Oct 2, 2003, at 06:10 Europe/Rome, Stephen McConnell wrote:

> Geoff:
>
> Just wanted to followup with you on the subject of 
> Merlin/Cocoon/Avalon/Blocks/etc.
>
> A few weeks ago there were several users@avalon people pushing for 
> greater collaboration with Cocoon on the Merlin/Cocoon block question. 
> That was the stimulus for taking a more proactive role in pushing 
> information out to the Cocoon list about what Avalon is doing.  On the 
> otherhand I'm kind of getting a sustained message "go away while we 
> sort this out ourselves" - and I don't want to appear to be pushing 
> something that isn't wanted.

I am, personally, not interested in collaboration at this point, no.

I see nothing to gain. No code that we can use "as-is", no design that 
fits problems that we haven't yet solved.

On the table there is just "compatibility" between Avalon Blocks and 
Cocoon Blocks. Which is something that might not be needed by the 
community at all.

This is why I asked to allow compatibility to happen in the future, 
would the need arise, but suggested to let the two communities 
independently come up with something that works first.

> I was wondering if you could give me some "private" feedback. In you 
> opinion should we be working towards Avalon/Cocoon collaboration or 
> should we simply come back in a year or eighteen months to see what is 
> happening?

That's what I suggested.

>   If its collaboration then some concrete things need to be considered 
> on the Avalon side and communication channels need to be established.  
> If not - there are migration issues related to ECM/Fortress that can 
> take a back seat in favour of other priorities.

? you are mixing concerns. migrating ECM to Fortress has nothing to do 
with block support.

> In the overall Avalon picture this has to be addressed as we move 
> towards a single Avalon solution - in the shorterm - the Cocoon/Avalon 
> relationship feels kind of mixed.

Cocoon is using the Avalon Framework, ECM and some Excalibur components 
(some of which are maintained entirely by cocoon committers). Nothing 
else.

Should we use more? if it makes sense, yes.

Why should we spend months in trying to come up with a solution that 
makes both Avalon and Cocoon happy for blocks instead of just 
implementing a design that we already spent almost a year designing? 
for what?

> Any thoughts that would maybe give me a clue on direction?

Anyway, the above is *my* personal vision. I would like to hear what 
others think as well.

--
Stefano.