The Apple-Intel analogy

[Reinhard Poetz <re...@yahoo.de>]

--- Sylvain Wallez <sy...@apache.org> schrieb:
> Giacomo Pati wrote:
> > If you mean Spring as the "rock-solid container
> used by thousands of 
> > people" than tell me why are you using a Mac while
> "ten-thousands of 
> > people use a IBM ThinkPad" ;-)
> 
> A very interesting comparison: Apple is currently
> moving to Intel CPUs!! 
> Why so? Because PowerPC is a dead end for their
> market, as IBM makes no 
> effort to produce good laptop CPUs. So Apple changes
> the engine, without 
> changing what's unique to them.
> 
> This is exactly the same for Cocoon: Avalon is dead,
> and we all agree on 
> this. So what's the point of adding dependency
> injection features to 
> Avalon? It's like adding Intel instructions to a
> PowerPC to prepare 
> migration. That's nonsense: you end up with a clumsy
> solution that 
> smells like a DI container but is not, and provides
> a mix of injection, 
> lifecycle interfaces and service lookup.
> Furthermore, it doesn't really 
> encourage people to move away from Avalon as its
> features are still 
> available to all components.

I think the Apple move to Intel processors is a good
example. Apple is changing its fundaments but the
building above, the operating systems, remains the
same and all your applications won't stop to work. The
average user won't even notice that the processor has
changed.

IMO Cocoon should go the same way. The recent thread
about a complete rewrite of Cocoon *really* scares me
and a lot of people I've talked to as it will break
compatibility for sure.

If I take Marc's proposal as some kind of common
understanding within the community on where we want to
go, I still fail to see why the revolution is
necessary. I also consider it as dangerous as it might
lead to fractions within the community and we start
again to split our limited time that we can dedicate
to the devleopment of Cocoon into two projects for
years (again).

--
Reinhard





	

	
		
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

Re: The Apple-Intel analogy

[Reinhard Poetz <re...@apache.org>]

Torsten Curdt wrote:

>> IMO Cocoon should go the same way. The recent thread
>> about a complete rewrite of Cocoon *really* scares me
>> and a lot of people I've talked to as it will break
>> compatibility for sure.
>  
> Fear has always been the main blocker for new technologies.

Well, I haven't talked about what my (many's) fear is: We have been talking 
about blocks for ages. After years we will get them. We are good in talking 
about design and architecture but the usual Cocoon committer can only dedicate a 
fraction of his time to enhance and improve Cocoon.

Considering this situation I have the fear that we will have a good concept (and 
maybe some prototyp) in the end, that will block all future improvments as 
everybody is waiting for the much, much better next revolutionary step.

Compared to this I like Daniel's vision much more because he outlines a way how 
we get major improvments evolutionary. After splitting up Cocoon in many small 
parts (blocks) and refactoring them to POJOs, we can reimplement the core which 
should become much simpler if the core has been stripped down to its minimum.
This also makes it much easier for us to keep our *current* userbase as they can 
follow us making small steps. This also has a positive impact on the quality 
because we never have the chicken-egg-situation that we are waiting for users 
that should use the new, shiny (alpha) version of Cocoon and they are waiting 
that the new Cocoon gets officially realeased. As Mr. Javaflow you should know 
this situation ;-).

I do not fear new technologies - I'm maybe the only one who is using Cocoon from 
trunk in a serious project - but I do fear making the same mistake that we did 
with 2.1 --> 2.2 again.

-- 
Reinhard Pötz           Independent Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}

                                        web(log): http://www.poetz.cc
--------------------------------------------------------------------

Re: The Apple-Intel analogy

[Torsten Curdt <tc...@apache.org>]

> I think the Apple move to Intel processors is a good
> example.

Same here!

> Apple is changing its fundaments but the
> building above, the operating systems, remains the
> same and all your applications won't stop to work.

That's not true ...you have to port applications to
the new platform. But Apple has prepared developers
very well on how to do the migration. Of course we
would have to that too.

> The
> average user won't even notice that the processor has
> changed.

Let's hope they will ;)

> IMO Cocoon should go the same way. The recent thread
> about a complete rewrite of Cocoon *really* scares me
> and a lot of people I've talked to as it will break
> compatibility for sure.

Fear has always been the main blocker for new technologies.

I thought it was already clear that what (I think) most
people want is not necessarily to really rewrite from
scratch but the freedom to reevaluate and change every-
thing if they think it's a good change ...without the
"no, we cannot do that to our existing customers"

There is no doubt we need migration strategies ...but
there is also no doubt we are currently locked into
some not even so clear and old contracts.

THIS is what people (or at least I) want to change.

<snip/>

> I also consider it as dangerous as it might
> lead to fractions within the community and we start
> again to split our limited time that we can dedicate
> to the devleopment of Cocoon into two projects for
> years (again).

I am sure it will also create fraction if we don't
move on with some innovations that are just too much
for the current codebase.

cheers
--
Torsten

Re: The Apple-Intel analogy

[Sylvain Wallez <sy...@apache.org>]

Reinhard Poetz wrote:
> I think the Apple move to Intel processors is a good
> example. Apple is changing its fundaments but the
> building above, the operating systems, remains the
> same and all your applications won't stop to work. The
> average user won't even notice that the processor has
> changed.
>   

For this migration, that's true, but...

> IMO Cocoon should go the same way. The recent thread
> about a complete rewrite of Cocoon *really* scares me
> and a lot of people I've talked to as it will break
> compatibility for sure.
>   

...remember a few years ago the migration from MacOS 9 to MacOS X: 
everything changed, and that was a complete rewrite. There is the 
MacClassic compatibility layer, that allows MacOS 9 applications to run 
on MacOS X. With some limitations though, since MacOS 9 applications had 
to be based on CarbonLib to have a chance to run on MacOS X.

At first, many users where angry because the new OS was breaking some of 
their applications and because it was changing their habits. But now, a 
few years later, no one would consider using again that old Mac OS 9. I 
bought some Macs in 1987, 1995 and my PowerBook in 2003. I *never* used 
MacClassic on my PowerBook.

My old Macs still work, and the 10 year old one is still used every 
week-end. Just as we still have projects here running on Cocoon 1 and 
are maintaining them. And contrarily to hardware, software doesn't have 
the problem of failing parts for which you can't find a replacement.

> If I take Marc's proposal as some kind of common understanding within the community on where we want to go, I still fail to see why the revolution is necessary. I also consider it as dangerous as it might lead to fractions within the community and we start again to split our limited time that we can dedicate to the devleopment of Cocoon into two projects for years (again).
>   

The architecture of the current Cocoon is too intimately tied to Avalon, 
and doesn't really help to handle the new needs of XML processing and 
webapp development. Cocoon must evolve or it will die.

Now we have to find our CarbonLib to prepare the migration to the next 
major revision. Currently, I see it as being the sitemap language which 
can be implemented on a different pipeline API, and the flowscript for 
which a compatible object model can be built. Although some level of 
compatibility can be provided, there will be some incompatibilities. But 
new projects won't care.

Sylvain

-- 
Sylvain Wallez                        Anyware Technologies
http://bluxte.net                     http://www.anyware-tech.com
Apache Software Foundation Member     Research & Technology Director