All -

thanks for the interesting feedback on, zope/plone-user lists and #zwiki channel. Based on this I see the following as a good roadmap.

- Plone needs native wiki-ish solutions that fit the Plone model. It's time to stop chasing Plone, remove the CMF/Plone support (simplifing code and skins), and focus on plain Zope 2 as our platform.

- Ideally there would be one last release to fix cosmetic issues with current Plone 3 support. Anyone who wanted Zwiki in Plone would use this version. This, call it Zwiki Classic, would enter mothball/deep maintenance mode. (We might call it 1.0. Don't freak out. I'm just saying.)

- New development would focus on a 2.x branch where we would drop backwards compatibility, do very aggressive cleanup and generally make our life easier. Other priorities would be all-unicode, ease of hosting, pluggability and modularisation, moving to zope3 technologies, and extracting reusable python/zope3 libs. This would be a refactor not a ground-up rewrite - we should be able to use it pretty much right away.

- Z3wiki (the all-zope3, ZPL zwiki codebase) might be able to use and help extract libs from above. I don't expect to work on z3wiki directly myself because Zope 2 is our mainstream appserver and because I prefer to spend most of my time in GPL-land.

So there is one possible path into the future, though I don't yet know how far down it we'll go. has a hundred subscribers, but I'm not hearing strong support/interest/need. And there are other projects and other implementation strategies to explore. One basic issue is that with wikis proliferating and traffic intensifying, 100%-dynamic, memory-intensive wikis are not always economic. Eg for slashdottings and for busy developers, an RCS-based solution like ikiwiki is attractive. And so on. Just pondering; we shall see. As always, further thoughts welcome.


Zope maillist  -
**   No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to