[ZWeb] Zope.org and New zope.org status
george donnelly
list@zettai.net
Thu, 09 Jan 2003 19:33:36 -0500
hi
> I think it's critical to look for ways to lessen the commitment and tap
> into extra manpower. Thus, I propose that nzo use Plone, for the
> following reasons:
>
> 1) They've already done a lot of cross-browser work. IMO, anybody that
> says cross-browser UI styling is someone not responsible for actually
> doing it. :^)
At the same time, making something cross-browser (v4 or v5 and above) *and*
uncomplicated (ie fast and easy to maintain) is not all that terribly hard.
Plone has a lot of javascript-ish stuff that *is* hard to make cross-browser
but at the same time is a PITA and is not always well-loved.
> 2) The Plone community will continue doing such work going forward.
> How much improvement will go into NZO after the launch?
yes but do you want zope.org to be *another* plone clone? zope.org still
needs a custom design.
>
> 3) If you compare the size of the Plone community to the nzo
> community... :^)
good point
>
> 4) Plone is built on CMF already, as is nzo.
>
> 5) Geez, they're a great Zope success story for Zope, it makes sense to
> collaborate with them and show confidence in what they're doing. If
> not, NIH rears it's head.
very true. it would be great to support plone in this way.
>
> 6) Plone can accomodate different looks and styles, so we could keep
> the nzo look (which, ironically, came from Plone).
This is true of the CMF as well.
> As an example, Andy recently migrated ZopeZen from his own Zope
> software to Plone, and it doesn't look anything like plone.org.
> ZopeZen is arguably the second most important site in the community.
> If Andy can migrate to Plone, I think zope.org can seriously consider
> it.
i think there would still be the content migration issue. All of the zope
zen content that was migrated was CMF-ish (and a recent version) to begin
with.
> 7) We could take the content objects for nzo and put them in the
> Collective, so they won't (hopefully) languish.
good point.
>
> 7) With Plone, a better nzo can arrive sooner (obviously a subjective
> statement).
it might be a quicker fix.
>
> Downsides:
>
> 1) We introduce a dependency on non-core software. (BTW, will nzo will
> use anything from the community?)
>
> 2) Some people don't like Plone. Like with CMF, it's hard to pin down
> the reasons.
basically because its slow. its just plain slower than stock CMF. also its
still a little immature and prone to occasional problems.
> 3) People claim Plone has a performance penalty. Not as much as the
> claimed penalty of CMF (which is being used for nzo), but a claimed
> penalty nonetheless. I don't think there are numbers, unfortunately.
> Maybe we could ask Andy.
i find stock CMF to be faster than plone (i think this is a combination of
zpt vs. dtml and the javascript that plone uses.)
> In summary, given constrained resources, I think the path of least
> effort and most ROI runs through Plone. And such a choice will
> demonstrate that zope.org is open to working with the Zope community.
>
> On to the volunteering...A call-to-arms in the Plone community might
> turn nzo from its current status into something we're proud of. I'm
> personally willing to participate and contribute hours. We were making
> pretty good progress working together last spring, it could happen
> again.
perhaps another issue might be how are people who have already volunteered
being integrated into the project? I volunteered in the suggested way and
was never contacted.
<-->
george donnelly - http://zettai.net/ - "We Love Newbies" :)
Zope Hosting - Dynamic Website Design - Search Engine Promotion
Yahoo, AIM: zettainet - ICQ: 51907738 - e:george@zettai.net