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


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

Reply via email to