[Zope-dev] Fishbowl not problem centered enough

[Jay, Dylan]

> -----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