Hello Zopistas.. a happy Valentine's day to all! Continuing with my spring cleaning theme over at http://zwiki.org/GeneralDiscussion , here are some musings. Like many of you, I'm always wondering where is the most useful place to spend my community hacking time. Sometimes Zwiki seems like the very best place; other times it doesn't. Development pretty much came to a full stop at times last year. So I'm kicking around some ideas. I'm pondering what slows down my Zwiki hacking. First, let me get one thing off my chest: for me, Python is a `blub <http://en.wikipedia.org/wiki/Blub>`_! There, I said it. Moving on.. then, there are the usual questions of project and platform maturity, legacy cruft, how many people actually use this thing, what is the benefit, what's the future potential, etc. Don't get me wrong, I expect Python and Zope 2 to keep growing and succeeding for a very long time. And so I guess Zwiki will continue to be used and perhaps grow in user base. At the current rate of development, though, we will not stay competitive with other software or even catch up with our own bug reports. Looking at current code, I am reminded that Zwiki 0.x is mature, built on early zope 2 architecture, and that cleanup continues to be expensive (compared to starting something fresh). Of course, many hands make light work. Imagine ten developers working on Zwiki at once - cleanup expense would no longer be noticeable, we could pretty much do whatever we want. That's not our current reality. Is it possible to find ten Zwiki developers now or in future ? I'm sure I could increase our numbers (from two active) by sustained effort, but how far and how smart a strategy that is I don't know. Another idea which inspired this post is to branch, mothballing 0.x as-is and moving development focus to a Zwiki 2.x where we would do aggressive disruptive cleanup. Say we did that. What would you throw out of Zwiki 0.x ? What would you keep ? This is to air these thoughts, solicit your ideas, and also a kind of ping to gauge support for the project circa 2008, I guess. Warm regards - Simon -- forwarded from http://zwiki.org/GeneralDiscussion#msg20080214142402-0800@zwiki.org Joyful Systems http://joyful.com
Simon Michael wrote:
This is to air these thoughts, solicit your ideas, and also a kind of ping to gauge support for the project circa 2008, I guess.
If I were designing a Wiki system for use with Plone today, I'd start with "wicked", the wiki linking feature of Plone, and extend it with a policy that provided wiki features like backlinks and an optional security policy of more free edits. That of course says nothing about existing ZWiki instances (which you may then need to migrate), nor does it cater to a Zope-only solution. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
I have a case where I need to redirect users from my Zope site to a third-party web site and send POST data that I generate. The only information I can find on RESPONSE.redirect relates to the GET format. Is there a POST version of RESPONSE.redirect and if so, how is the POST data included? Thanks, Jonathan
Hi, Jonathan wrote:
I have a case where I need to redirect users from my Zope site to a third-party web site and send POST data that I generate.
The only information I can find on RESPONSE.redirect relates to the GET format. Is there a POST version of RESPONSE.redirect and if so, how is the POST data included?
No its not. It helps to have an eye on the HTTP-Spec some time :-) People circumvent this limitation sometimes by means of Javascript. (Basically posting a form) - often you can skip the Javascript and let the user send the form intentionally. BTW, this isn't related to ZWiki :-) Regards Tino
Simon Michael schrieb:
Hello Zopistas.. a happy Valentine's day to all!
as martin said (or hinted) before me, a new wiki solution needs to be seamlessly integratable into plone. I like zwiki very much and still use it often. but rarely in new projects. the userinterface is to different from plone. thanks for the incredible useful zwiki you provided us with. if you move towards something plonelike, I would be happy to help. robert
robert rottermann wrote:
Simon Michael schrieb:
Hello Zopistas.. a happy Valentine's day to all!
as martin said (or hinted) before me, a new wiki solution needs to be seamlessly integratable into plone.
I like zwiki very much and still use it often. but rarely in new projects. the userinterface is to different from plone.
thanks for the incredible useful zwiki you provided us with.
if you move towards something plonelike, I would be happy to help.
Still I'm not so much a friend of Plone. While having the hooks in place, a lightweight wiki-core would really be great. Perhaps split into document type/parser/editor, storage and link calculation engine, search&catalog and security? Then just some glue code to adapt to plain zope, CMF, Plone, Five... I mean the biggest improvement would be skipping that DTML stuff ;)) Regards Tino
Tino Wildenhain wrote:
Still I'm not so much a friend of Plone. While having the hooks in place, a lightweight wiki-core would really be great.
A lightweight wiki engine that was agnostic to the framework used would be *awesome*, especially if it let you customise the dialect of the wiki easilly.
Perhaps split into document type/parser/editor, storage and link calculation engine, search&catalog and security?
I'd mainly be interested in the parser for text with the ability to plug in storage and finding of other pages. ie: would be lovely to see this as just a python package with no ties to Zope, etc cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
All - thanks for the interesting feedback on zwiki.org, 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. zwiki.org 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. -Simon
All - thanks for the interesting feedback on zwiki.org, 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. zwiki.org 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. -Simon
participants (6)
-
Chris Withers -
Jonathan -
Martin Aspeli -
robert rottermann -
Simon Michael -
Tino Wildenhain