-----Original Message----- From: Ken Manheimer [mailto:klm@digicool.com] Sent: Thursday, 21 June 2001 2:53 AM To: zope-dev@zope.org Cc: Casey Duncan; Jay, Dylan; Paul Everitt; Jim Fulton Subject: Re: [Zope-dev] Fishbowl not problem centered enough
On Wed, 20 Jun 2001 09:24:40 -0600, Casey Duncan <cduncan@kaivo.com> wrote:
"Jay, Dylan" wrote:
Fishbowl is a great idea but it seems to be that its
solution focused rather
than problem focus. Perhaps if you had a page that listed all the problems with zope or problems that need to be solved that isn't as easy as it could be with zope.
I think it would be helpful to have a "big picture", with goals and objectives, into which to fit the pieces - would that address the kinds of things you're talking about?
"big picture" is good but its not what I mean. What I mean is a list like this ---------- ZODB is not fault tolerent - ZODBReplication No way to use Zope with source control - DirectoryStorage - ZODB - CVSStorage - ZODBFileSystemSynchronization Need clearer seperation between presentation and code - HiperDOM etc etc --------- What I'm suggesting is turning the focus on its head. If every day your looking at problems rather than proposed solutions it promotes the following - Ideas about alternative solutions - Focused debate about tradeoffs between alternatives - a clear way to determine priority of proposed solutions by determining priority of the problems they solve. People can vote on the problems to gauge the need in the community. This is something that you guys need. eg No one at work will take zope seriously if they can't use source control to intergrate into our existing processes. If I'm alone then thats cool, but if lots of people are in the same boat but arn't about mailing the dev list to tell everyone then you'll never know and lose all those potential zopisters. Voting could be done by giving each "problem" a page with a special tag. Every user gets 5 votes to place on any page with the tag. When ever the problem changes status then everyone who voted gets notified. When the problem is solved all those votes get refunded. If someones priorities change then they just move their votes around. (The java bug parage was an inspired idea IMHO)
The fishbowl is also "pull" technology, and so it is time-consuming to keep up with the developments. I personally find it to be cumbersome, limiting and not really conducive to actually getting stuff done.
I've really wanted to enable people to subscribe to notification about changes to wiki pages, and to notifications about additions to the wiki. Unfortunately, i didn't have time to get to that in the WikiForNow project. As soon as i'm clear form a current project i *may* be able to concentrate on at least formulating a reasonable quick-and-dirty way to do notifications, and getting it done for the short term. Whether or not it's me doing it, i think we're going to be bringing more attention to these issues.
I wrote a quick and dirty one for this. I'll include the code at the bottom of the email. However someone recently suggested something better. The idea that you can send email to a wiki page. To take this futher imagine if every wikipage is a mailing list. Everyone who adds to it becomes a subscriber or you can subscribe manually to become a lurker. Then every update gets mailed to everyone. Then every reply becomes a comment at the end of the page. Perhaps every wikipage created from the original page inherits its subscribers. Of course you can unsubscribe at any time (have to be real easy to do like one click at bottom of email). Email addresses would be something like ZODBReplication@wiki.zope.org or something. So what problem does this solve? - Lack of awareness of wiki changes - Email discussion is easier than wiki discussion but essentially the same thing however they get recorded in different places with no connection between each other - No more "good idea, but record it on the wiki" comments Anyway the code I wrote (just for stright subscription) went like this. It relies on an XML document to keep the subscribers but that can be replaced by some kind of map. It also relies of ZCron to do the checks every 5min or so. If you guys added a flexible change notification hook (Listener talker pattern) it would make like much easier. eg The idea of subcribing to events on any object like "change" and "add" events. add_subscriber(self, user, page_name) ------------------------ doc = self.subscribers body = doc.getElementsByTagName('subscriptions')[0] n = doc.createElement('Notify') body.appendChild(n) p = doc.createElement('Page') p.appendChild(doc.createTextNode(page_name)) n.appendChild(p) u = doc.createElement('User') u.appendChild(doc.createTextNode(user)) n.appendChild(u) remove_sbscriber(self, user, page_name) ------------------------ doc = self.subscribers.getElementsByTagName('subscriptions')[0] sub = [] for e in doc.getChildNodes(): if e.getNodeType() == 1: page = e.getElementsByTagName('Page')[0].getFirstChild().getData() the_user = e.getElementsByTagName('User')[0].getFirstChild().getData() if page == page_name and user == the_user: doc.removeChild(e) return sub get_subscibers(self, page_name) -------------------- doc = self.subscribers.getElementsByTagName('subscriptions')[0] sub = [] for e in doc.getChildNodes(): if e.getNodeType() == 1: page = e.getElementsByTagName('Page')[0].getFirstChild().getData() if page == page_name: user = e.getElementsByTagName('User')[0].getFirstChild().getData() sub.append(user) return sub and then a ZCron run method doPageNotifications(self, lastUpdate) -------------------- res = [] for page in self.get_updated_pages(lastUpdate): for user in self.get_subscribers(page.id()): res.append((page,user)) self.mailNotification(self, None, user=user, page=page.id(), url=page.absolute_url()) return res