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
