-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul Everitt wrote: > > On May 18, 2005, at 10:46 PM, Reinout van Rees wrote: > >> On Wed, 18 May 2005, Paul Everitt wrote: >> >> >>> Zope 3 made some specific decisions in the beginning: (a) it wasn't >>> for end users, but for developers to create something for end users, >>> and (b) it wasn't tied to CMS. >>> >>> This latter part means that putting what's needed for a ECM into >>> Zope 3 itself, ain't gonna happen (and shouldn't). Zope 3 is an >>> application server. >>> >> >> Trying to summarise for myself to see if I'm getting it... >> >> * Current situation is zope2 plus the CMF layer plus a lot of >> CMSs (plone, cps, silva) which all to a lot of similar things. >> >> * Zope3 is more or less a plain application server, so it's missing >> most of what's now in CMF. (Well, skins etc. are there, so it's a >> bit of a mix). >> >> * So z3lab is an effort to maximize the CMF-like layer to keep silva, >> cps, plone as lightweight as possible. Maximizing the common stuff, >> so to say. > > > I'll second Stefane's score and nominate you as Zope Historian of the > Year. :^) > > Couple of points I'd add: good quality> > 1) The CMF turned out to be as much (IMO) of a next-gen app server, > tackling as many problems at the app server layer as it did at the CMS > layer. > > 2) For the Z3 ECM effort, I'm as interested in the sharing part as I am > the layer. I'd rather have good cooperation and mediocre code than the > reverse, as: I'm sorry, I'm afraid it's not an acceptable statement. We need good cooperation for sure and a *very* good quality for the resulting product including *very* good code ! This is not negotiable ;) J. > > o Zope developers shouldn't have multiple frameworks to support for > components. > > o Customers shouldn't see a barely-known framework, which is then > divided in 3 slices. > > o Many things in ECM circa 2005 are commodity, non- differentiators, > and duplication > is thus a liability, not an asset. > > o Some of the truly hard issues (like the "STORAGE" section in > Michael's note) need > maximum baking if we're going to convince million-doc customers to > use it. This > means putting all the learning, experiences, refinement, and proof > behind a common > best-of-breed. We don't have a convincing story otherwise, IMO. > I'll put Florent's > work on repositories in that category also. > > This idea of "sharing work", with emphasis on the sharing, means we > must bootstrap a culture of cross-pollination. This is a non- technical > issue, and I think it requires deliberate steps and attention to reach > the goal. > > Nuxeo started by putting 2 full-time, very-high-powered developers on > this effort that's been in talk-mode for a while. Martijn added his > kick-off note about integration and leveraging other work at each > layer. I hope to see more posts where each of us evaluates stuff from > other camps and works to leverage it. > > I want one shared component, even hello freakin' world, in each CMS, in > 2005. Or maybe, Q1 2006. :^) > > Our competition isn't each other. Our competition is the overpriced, > well-marketed, closed solutions in the ECM space. None of us has the > resources to compete alone. Each of us has something the other needs. > > --Paul > > - -- Julien Anguenot | Nuxeo R&D (Paris, France) CPS Plateform : http://www.cps-project.org mail: anguenot at nuxeo.com; tel: +33 (0) 6 72 57 57 66 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFCjFXlGhoG8MxZ/pIRAsHZAJ9B5cTFT6P6YYnEQxBZXi9wG8+VNQCfciY4 UIZ284Vajc7afJjRUzAZi7g= =raBq -----END PGP SIGNATURE-----
Hosting: Nuxeo: Zope service provider