[Zope-dev] Re: [Zope-Coders] July Bug Day Roundup
On Sat, 31 Jul 2004, Chris Withers wrote: Also, there's now documentation of what the various collector states mean at: http://dev.zope.org/CVS/CollectorStatuses Some points of it are still up for discussion, so please join in at [EMAIL PROTECTED] if you have a view! I have a pretty different conception of the states. I've created another page, linked into chris', with my alternate framing, at: http://dev.zope.org/CVS/CollectorStatusesAlt Obviously, we need to resolve the differences so all the supporters use the states the same way. I hardly participate in the zope collector (though i do use collectors all the time for a lot of projects), so i'll defer to the people who actually use it - but want to suggest this framing because i think it'll help reduce the chaos. All in all, a massive 64 issues were dealt with! Many thanks to all who helped out, look forward to seeing as many of you as possible for the next one at the end of August... Thanks to all for making zope better, and particularly to chris for shepherding the effort! Ken [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Zope-Coders] Collector Status Meanings
On Fri, 30 Jul 2004, Chris Withers wrote: Apologies for the cross-posting, but I think this is relevent to all these lists. I think this is a valuable discussion. I don't think cross-posted discussions work, though, so i'm replying in the various groups (except zope-collector-monitor, which is only meant for collector-originating submissions) with a followup to zope-coders. I've summarised the meaning of the various collector states here: http://dev.zope.org/CVS/CollectorStatuses Please let me know if you disagre with any of that, although I'm pretty sure they're right and will argue with anyone who thinks otherwise ;-) My intent for the states is different from what you suggested, in some cases significantly. It may be that the practice is more like you describe and makes more sense, i dunno, but here's what i intended: Pending: Issues that have not yet been settled or assigned to some supporter, and warrant attention. Your description, issues that haven't been considered, assumes that issues are always assigned or settled when they are examined, while i think some issues can remain in the pending state awaiting resource availability. Accepted: Issues that some supporter(s) has responsibility for resolving it, and it is not yet resolved. Your description says that some supporter has assessed the issue as warranting repair, and later says that the the issue has an assigned supporter. I think it's a lot clearer to directly say that an accepted issue has a supporter responsible for resolving it. Rejected: Issues that are settled as being somehow invalid or outside the scope of the system the collector serves. Resolved: Issues that are settled as having been solved. Deferred: Issues that are not assigned or settled but warrant revisiting at some later occasion. This enables, for instance, putting an issue aside until more information is collected. Wontfix: Issues that are settled as ones that won't be fixed. These issues are within the scope of the collector, but would require more effort than they're worth. (Sustained lack of a champion who will take responsibility for solving the issue is one sign of that.) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope.Com Geeks] Re: [Zope-dev] zope-dev list policies
I noticed this when it went initially went by, but didn't have time to follow up. The upshot is that there is absolutely no way *under the current arrangement* that this is going to happen. I can see a way to swing it, requiring earnest volunteer effort. Here are the details. Being the administrator of many of the zope lists (probably over ten and below twenty), i am already dismayed by the challenge of the typically thirty to one hundred held spam messages, bounces, and other effluvia i have to handle *per day*. I do not know how many of the legitimate list messages would additionally be held and require more attention (with the current mailman implementation, it takes a lot more fuss to approve a held message than to discard it), but the load is already untenable, so one more is too many. There is an option, however. It's possible to add moderators to lists, separate from list administration privileges. I would be willing to set the lists to hold non-member postings, *if* there were volunteer moderators that would actually take care of some significant portion of the load - ie, i would not have to approve one non-member (alternate address) posting. (I would not mind occasionally approving a non-member/alt-addr posting if the volunteers reduced the spam/bounce handling efforts in the process.) That's the situation. Are there people that would be willing to volunteer for moderation duties? (Say which lists when you reply - and make sure to cc me directly, since i can't read most of the lists i moderate.) Ken On Thu, 24 Jun 2004, Andrew Sawyers wrote: Leonardo Rochael Almeida wrote: +1 for member-only posting On Wed, 2004-06-16 at 22:24, Tim Peters wrote: Over on the zope and zope-dev lists, there's currently agitation to make them members-only mailing lists. The point is that spam could not get thru then (unless posted by a member). What would zodb-dev members like? [...] +1 I propose this policy extends to all ZC managed community lists. Andrew Sawyers ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope.Com Geeks] Re: [Zope-dev] zope-dev list policies
What proportion of the list traffic comes from valid members who are posting from alternate accounts? On Thu, 24 Jun 2004, Andrew Sawyers wrote: Ken Manheimer wrote: I noticed this when it went initially went by, but didn't have time to follow up. The upshot is that there is absolutely no way *under the current arrangement* that this is going to happen. I can see a way to swing it, requiring earnest volunteer effort. Here are the details. Being the administrator of many of the zope lists (probably over ten and below twenty), i am already dismayed by the challenge of the typically thirty to one hundred held spam messages, bounces, and other effluvia i have to handle *per day*. I do not know how many of the legitimate list messages would additionally be held and require more attention (with the current mailman implementation, it takes a lot more fuss to approve a held message than to discard it), but the load is already untenable, so one more is too many. Why would we hold non-member postings for review? Why not simply outright reject them? ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope.Com Geeks] Re: [Zope-dev] zope-dev list policies
On Thu, 24 Jun 2004, Andrew Sawyers wrote: Ken Manheimer wrote: What proportion of the list traffic comes from valid members who are posting from alternate accounts? A huge percentage was - I don't know how much is making it through to the lists though. I'm hearing a lot of complaints from people either third party, seeing it in IRC or from emails off the lists. I've recently added an increased amount of header and body checks which were not being applied yesterday as well as increased spam reject features. This should help - in any event now that it's being blocked at the MTA, Mailman's load on the server has went from 2 -3 to ~.5 on the server in the last hour. Andrew Huh? I was specifically talking about the legitimate postings, valid members who are posting from alternate accounts, sounds like you're talking about spam. On Thu, 24 Jun 2004, Andrew Sawyers wrote: Ken Manheimer wrote: I noticed this when it went initially went by, but didn't have time to follow up. The upshot is that there is absolutely no way *under the current arrangement* that this is going to happen. I can see a way to swing it, requiring earnest volunteer effort. Here are the details. Being the administrator of many of the zope lists (probably over ten and below twenty), i am already dismayed by the challenge of the typically thirty to one hundred held spam messages, bounces, and other effluvia i have to handle *per day*. I do not know how many of the legitimate list messages would additionally be held and require more attention (with the current mailman implementation, it takes a lot more fuss to approve a held message than to discard it), but the load is already untenable, so one more is too many. Why would we hold non-member postings for review? Why not simply outright reject them? ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
RE: [Zope.Com Geeks] Re: [Zope-dev] zope-dev list policies
On Thu, 24 Jun 2004, Tim Peters wrote: [Ken Manheimer] I noticed this when it went initially went by, but didn't have time to follow up. The upshot is that there is absolutely no way *under the current arrangement* that this is going to happen. I can see a way to swing it, requiring earnest volunteer effort. Here are the details. I think you have something different in mind than was being discussed. Members only comes in several flavors. You seem to have the ... and non-member posts are held for moderator review flavor in mind. That wasn't suggested. Two other flavors were: - ... and non-member posts are rejected. No messages are held for moderator review then. A would-be poster with a legitimate email address gets an auto-generated rejection reply msg. Since most rejection msgs would go to bogus addresses on spam and virus email, m.z.o gets another bounce back for most attempts to send a rejection reply. - ... and non-member posts are discarded. No messages are held for moderator review then. Non-member posts go to the bit bucket, without comment or recourse. In either mode, essentially, list members would be able to get postings to the list only from their registered account. I don't have a confident guess about whether that would be prohibitive to any or many. I suppose we could try it and see whether how it sits with people. There's also the incidental considerations - both modes have drawbacks. As you point out, non-member-posting-rejection increases the incidental mail spew being sent to zope.org, not insignificantly. Non-member-posting-discard mode means some percentage of posters will have their postings discarded, and some percentage of those will fail to notice it never showed. I think that kind of failure mode leads to really bad, insidious problems, and don't think it's an acceptable kind of noise to put into a system, so i would be a solid -1 on it. So i could see giving a try to non-member-posts-rejected, if the membership thinks the added inconvenience is worth the reduced spam. I have the impression, though, that the spam on most of the high-traffic zope.org maillists is relatively low-proportion. Am i mistaken? [...] There is an option, however. It's possible to add moderators to lists, separate from list administration privileges. I would be willing to set the lists to hold non-member postings, *if* there were volunteer moderators that would actually take care of some significant portion of the load - ie, i would not have to approve one non-member (alternate In my (limited but real wink) experience, this doesn't work. Without a single clear owner, postings held for review eventually grow to unmanageable bulk. Nobody enjoys the moderation task, it does consume time, and when there are multiple moderators they all eventually reach a point of believing that someone else can handle it for a while. After a few days go by like that, a co-moderator who is able to make some time logs in and finds such a backlog that they decide they have more urgent work to attend to. Then it snowballs out of control. We had a clear example of this about a month ago, when the backlog of python-help messages waiting for review reached thousands. At that point the only realistic option was to discard all of them, effectively making python-help the ... and non-member posts are discarded list flavor. Well, that's useful info. The only ... and non-member posts are held for review list I moderate that works is the PSF Board mailing list. That works because I'm the only moderator, legit traffic on it is very light, and I know enough Visual Basic to automate the reject/approve process without leaving Outlook wink. Reject (actually, discard) is pretty easy - you just have to reply to a particular attachment in the held-message notice. (I **wish** the confirmation message for the discard would indicate that a discard happened - instead, it says Confirmation succeeded, which is nearly worse than no feedback at all, because it sounds like my discard instrucation was taken as an approval. But i haven't taken the time to do anything about it, sigh.) Never tried approval-via-reply, since i'm afraid of screwing up the header, and mostly don't have to do emailled approvals, anyway. Ken [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Public CVS and SVN outage, 5:00 to 7:00 PM EST today (21:00-23:00 GMT)
As andrew mentioned last friday, we're migrating our public version- control services to a new machine this evening - allotting two hours from 5:00 PM EST (21:00 GMT, i think). If all goes as expected, the only overt difference will be the return of pserver service. (The new machine is signficantly more capable, hardware wise, so tarball production and maybe even checkouts could be appreciably quicker.) Some of the services on the old machine will be reachable during part of the migration time, but readonly - checkins and key deposits will be disabled. Any write activities that get past because we neglected to block them are not guaranteed to be preserved across the transfer. I'll post a reminder soon before the outage time. Questions, concerns, let me know. Ken Manheimer [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Reminder: Public CVS/SVN outage, 5:00 to 7:00 PM EST / 21:00-23:00 GMT
Reminder - CVS and SVN will be basically unavailable between 5:00 to 7:00 EST (21:00 to 23:00 GMT) this evening - in 1/2 hour from the time i send this message. On Thu, 17 Jun 2004, Ken Manheimer wrote: As andrew mentioned last friday, we're migrating our public version- control services to a new machine this evening - allotting two hours from 5:00 PM EST (21:00 GMT, i think). If all goes as expected, the only overt difference will be the return of pserver service. (The new machine is signficantly more capable, hardware wise, so tarball production and maybe even checkouts could be appreciably quicker.) Some of the services on the old machine will be reachable during part of the migration time, but readonly - checkins and key deposits will be disabled. Any write activities that get past because we neglected to block them are not guaranteed to be preserved across the transfer. I'll post a reminder soon before the outage time. Questions, concerns, let me know. Ken Manheimer [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] RE: [Zope-Coders] Public CVS and SVN outage, 5:00 to 7:00 PM EST today (21:00-23:00 GMT)
Yay! On Fri, 18 Jun 2004, Tim Peters wrote: [Ken Manheimer] Most of the keys were not moved - i'm copied them, and you should now be good to go. Yay! Thank you, Ken. I'm back in. This is exactly what a programmer wants to hear when he's struggling to make a critical bugfix release against an unforgiving deadline wink. Double-checked, and both CVS and SVN writable checkouts are working here again. Thanks! sleeping-is-such-sweet-sorrow-ly y'rs - tim ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Public CVS/SVN back
Let the checkouts, checkins, and repository browsing continue!-) Took a little longer only because of problems with transfer of another machine. I think all the cvs.zope.org/svn.zope.org services are back in place - and probably noticably faster. Be alert for anything amiss, though - this was a signficant bodily relocation of numerous bits, and it's possible i missed something. Ken Manheimer [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Bug Day status report (fwd)
[This was mistaken for spam by our filter, and i was too quick to confirm it as spam...] -- Forwarded message -- Date: Fri, 28 May 2004 18:02:50 -0400 From: Paul Winkler [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Bug Day status report Just a quick status report on today's Bug Day... 10 bugs resolved, 5 set to won't fix, 4 rejected. RESOLVED: #1213, #852, #1293, #1355, #1265, #1352, #1094, #993, #1132, #596 WONTFIXED: #1193, #329, #1098, #1045, #981 REJECTED: #639, #1238, #489, #1297 The #zope-dev channel is quiet now, but feel free to hop in and rev it up again :-) -- Paul Winkler http://www.slinkp.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] RE: Re: [Collector] Strange reject policy
On Thu, 6 May 2004, Tim Peters wrote: [Ken Manheimer] All the actions are verbs, won't fix is not a verb. Can you suggest a verb the more clearly indicates the result is won't fix? Sorry, I got lost on the first sentence: what difference does it make to anything whether they're verbs, adjectives, a mix, ...? They're all just cryptically abbreviated answers to the question what do you want to do with this report?. Hmm. It can sometimes pay off in workflow configuration to consistently pick verbs that describe the actions in a generic way, so the workflows are consistent with other workflows for similar but separate activities. Sorta like generic APIs. Taking a step back (with a well aimed nudge), it doesn't look like this is really helpful here. I'll change it the action name to wontfix. (It'd be painful to accommodate punctuation in the action or state names, so if that spelling is too obscure, refuse may still be preferable.) (Is it just me, or is there sometimes a fine line between consistency and foolish consistency?) enquiring-small-minds-want-to-know'ly, Ken [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Re: [Collector] Strange reject policy
On Fri, 7 May 2004, Chris Withers wrote: Ken Manheimer wrote: All the actions are verbs, won't fix is not a verb. Do we have to be this pedantic? I wasn't meaning to be pedeantic. Sometimes inconsistencies in tense, grammatical form, etc, can make a web form unbeably confusing - what's right is not always clear. Tim's identifying the question the users will have in their minds - what do you want to do with this report - rang true, and addressed my concerns. I'm going to change the action to wontfix. verb the more clearly indicates the result is won't fix? (While the distinction between refuse and reject is subtle, reject distinctly implies to me a defect in the request, while refuse does not.) Yeah, but refuse doesn't have any logical associate with the won't fix state for me, so it's a very unintuitive name... The fact that you couldn't find the intended action when you first looked is an indication that the action isn't very clear. That said, sometimes the simplest clearest thing for one person isn't so for another, or is misleading (particularly to the chronically literal minded like me). In this case, though, wontfix will probably be clear to everyone - if they can get past the smashing together of the two words. I'd have to change other stuff to deal with a delimited pair of words, and don't want to mess with that if i can avoid it. Ken [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Dis-allow anonymous bug posting?
On Fri, 7 May 2004, Casey Duncan wrote: On Fri, 07 May 2004 09:56:45 +0100 Chris Withers [EMAIL PROTECTED] wrote: Tim Peters wrote: While that *should* be a good example, it isn't: I only knew that bug existed because someone closed it on Bug Day (and I'm subscribed to the Collectors, and read the email they generate). *bangs head against desk* Some bugs are so vaguely described nobody could guess -- and when they're anonymous too, there's no effective way to get more info. Those ought to be closed. Indeed. How about removing the ability for people to post bugs withotu specifying n email address? And, if they do specify an email address, using that to contact them by sending notification mails to it? No, some very valuable bugs are submitted anonymously. People can be very paranoid (rightly) about their privacy. We do want to encourage bug submissions even if that means more noise. Right. The business rationale for allowing anonymous postings was it's kinda bogus to require someone to become a member of the community in order to do the community the favor of submitting a bug report. AFAIK the collector does mail the poster on state change if they have an email address. I think that's right. I worried a little bit about the potential for mischief, but not much, and it hasn't proved to be a problem. For all I know, this happens already, but people don't perceive it as happening so the ythink anonymous bug postings will never be heard from and so close them straight away as anonymous, therefor we don't care Nope, many times we do care. But when we don't we will close them. To be clear: big -1 on restricting anonymous posting I don't think non-member posting is going to be restricted. Ken [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] cvs.zope.org wedged, we're looking into it
cvs.zope.org is wedged - you can connect to it (ping, web, ssh) but not get any further. We've got a call in for attention, hopefully it'll be back available soon... Ken [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: RE: Re: [Collector] Strange reject policy
On Fri, 7 May 2004, Dieter Maurer wrote: Ken Manheimer wrote at 2004-5-7 09:42 -0400: ... It can sometimes pay off in workflow configuration to consistently pick verbs that describe the actions in a generic way You can view won't fix as a verb, like in we won't fix this bug. Well, the action now is called wontfix. (Next time i or someone gets time, it would not take much to repair my stupid misunderstanding about .listFilteredActionsFor() to get a nicer Won't fix lable associated with the action.) I must say (since the conversation's continuing), i still like refuse. If there were a chance that collector issues were to be managed with other kinds of requests - for access, property, appointments, etc - then i could see where wontfix is too specific - they could all be acted on with accept, refuse, reject, etc. But that generalization probably ain't gonna happen, not with this incarnation of the collector. Also, the action for taking on a request in order to fix the problem is not called Will fix, it's accept. Refuse is a nicer complement than wontfix. Still, wontfix is easier to recognize in the context of bug reports, so what the heck. Ken [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [Collector] Strange reject policy
On Thu, 6 May 2004, Chris Withers wrote: Chris Withers wrote: Yay! Does this mean we have a fully functional wont fix state now? It does appear to, woohoo! Can we change the action name from Refuse to Won't Fix? I took a while to find it... All the actions are verbs, won't fix is not a verb. Can you suggest a verb the more clearly indicates the result is won't fix? (While the distinction between refuse and reject is subtle, reject distinctly implies to me a defect in the request, while refuse does not.) I'm hoping the difference is clear enough to be mnemonic, once you get it, at least. One small thing i think would be a big help would be to include html titles on each action so that browser mouse-over help bubbles would indicate the effect of each action. I don't even recall whether there's any help for the issue-followup form, but some text there could also be um helpful. (Patches appreciated.) Ken ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [Collector] Strange reject policy
On Thu, 6 May 2004, Andreas Jung wrote: --On Donnerstag, 6. Mai 2004 12:37 Uhr +0100 Chris Withers [EMAIL PROTECTED] wrote: Ken Manheimer wrote: Done. The piece you were missing is that the categories are actually states in the collector_issue_workflow. I added a Wontfix state and a refuse transition (bringing to a total of three the transitions by which issues are dodged:), and hooked them into the existing lattice. Yay! Does this mean we have a fully functional wont fix state now? A state we_can_live_with_that would be fine as well :-) That's either Reject or Defer with We can live with that (/for now). body. I can envision a little action qualifier text box, where the supporter can put in a brief message that describes the reason for their action. It would (in my fantasy vision) have an accompanying select box that is populated with the catalog-collected uniqueValuesFor() for that action. (Javascript would jam the values in the select box when the supporter picks an action, from the selections for all the available actions prepopulated in a hidden field). This way the supporter could add a new reason, if none of the conventional (already-in-use) ones suit. While i love this prospect - fits my ideal of adaptive collaboration - i'm not sure the extra precision outweighs the extra complexity - and who has time to implement this, anyway?-) Ken ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [Collector] Strange reject policy
On Thu, 6 May 2004, Lennart Regebro wrote: From: Ken Manheimer [EMAIL PROTECTED] All the actions are verbs, won't fix is not a verb. Can you suggest a verb the more clearly indicates the result is won't fix? Tough one... Live with Ignore Keep this bug as is Zenify Featurize (as in This is not a bug, it's a feature) Shove under carpet Forget Procrastinate Pretend to be deaf For any of these that you were suggesting in earnest - i think refuse is more direct. (I would be tempted by one that went, la la la i'm not listening i can't hear you even though it isn't a verb, and it'd make the form twice as wide...-) Ken ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [Collector] Strange reject policy
On Thu, 6 May 2004, Leonardo Rochael Almeida wrote: On Thu, 2004-05-06 at 11:56, Lennart Regebro wrote: From: Ken Manheimer [EMAIL PROTECTED] All the actions are verbs, won't fix is not a verb. Can you suggest a verb the more clearly indicates the result is won't fix? Tough one... Live with Ignore Keep this bug as is Zenify Featurize (as in This is not a bug, it's a feature) Shove under carpet Forget Procrastinate Pretend to be deaf How about Refuse to fix? How is that better than what i implemented, Refuse? (Or maybe you missed that, since it's not in the excerpt context?) As the discussion has proceeded i'm becoming more convinced that refuse is fine... Ken [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [Collector] Strange reject policy
On Thu, 6 May 2004, Lennart Regebro wrote: Or maybe Deny as a action? Sounds less angry than reject and refuse. What's being denied - the request to fix the bug, or the validity of the bug report? Refuse suggests only that we are refusing to fix the bug, there's no implication that the bug request is inaccurate. (As a noun, refuse has the connotation of garbage, but there's no tinge of that when used as a verb.) Ken [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [Collector] Strange reject policy
Chris McDonough [EMAIL PROTECTED] wrote: I think there needs to be another category named wontfix that doesn't imply that it will ever be fixed like deferred seems to. This category should also be selected in the default search settings. Later, Chris McDonough wrote: On Fri, 2004-04-30 at 13:59, Casey Duncan wrote: I volunteer Chris to implement it ;^) Just tried. I thought it was just a setting in the ZMI, but it's not. :-( Someone go get Ken!! ;-) :-) Done. The piece you were missing is that the categories are actually states in the collector_issue_workflow. I added a Wontfix state and a refuse transition (bringing to a total of three the transitions by which issues are dodged:), and hooked them into the existing lattice. This was easy. Other issues with our collector/issue-handling process are not so easy (particularly the security controversy). I'm going to try to take some responsibility for getting attention on those issues, since i have a bit of between-deadlines breathing space. Ken [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: emacs/pdbtrack users - enhanced to handle Zope's Script (Python)
Correction - use the HEAD version, so you get any fixes as they develop: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Misc/python-mode.el?rev=HEADcontent-type=text/vnd.viewcvs-markup -- Ken [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Zope-Coders] Zope anonymous CVS temporarily offline
On Tue, 21 Jan 2003, Martijn Pieters wrote: Due to the CVS vulnerabilities disclosed today, we have temporarily shut down anonymous CVS access to cvs.zope.org through pserver. We'll reenable this when we have upgraded CVS on the server. People with write access through SSH and the web interface at http://cvs.zope.org are still available. Adam has upgraded the CVS installation and put pserver back online, so public CVS operations should be back to normal... -- Ken [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Segregation of the Zope2 and Zope3 checkins implemented
I've just committed the change to the file that dictates checkin notice routing so that Zope3 checkins are directed to the [EMAIL PROTECTED] mailling list, instead of being included in the [EMAIL PROTECTED] list. For those of you on the latter list interested in continuing to get zope3 checkins, subscribe to the zope3-checkins list at: http://lists.zope.org/mailman/listinfo/zope3-checkins Happy hacking! -- Ken [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] References to hypertext templating languages
Don, it sounds like HyperTIES Markup Language addresses some similar purposes in similar ways to Zope Page Templates. There are also some significant differences, which may interest you. ZPT has some distinctive features particularly aimed to promote ease of collaboration between web designers and programmers (or between those two sides of a developer, working with themselves.-) Chief among those features is use of tag attributes for computation hookup - variable access, conditionals, loops, method invocation, etc. By using tags on standard XHTML, the results of adapting a page for hookup with the rest of the application retains the structure and parsability that the designers originally created. The original structure is preserved, and conversely, typical design tools preserve foreign tags (generally, ignoring them, maybe even colorizing them distinctively), so we avoid disruption in both directions. (It's a pleasure to be able, as a programmer, to take designer's markup and add the right tags, capitalizing on their designs without disrupting them - and to be able to trade the result back and forth, evolving it without having to retrofit changes again and again. I've done this, on customer projects, and was **not** able to do so when we were using DTML.) The issue about order of tags seems to be a misunderstanding - the order being described was order of _execution_ - precedence of the tags, to serve the programmers purpose. For more information, see the TAL (Template Attribute Language) specification: http://dev.zope.org/Wikis/DevSite/Projects/ZPT/TAL%20Specification%201.4 The discussion about procedural versus templating language may be based on misuse of terms. I think the issue is block-structured versus page/layout markup. It's common to see templating languages that hookup to underlying programming logic by interspersing block-structured code with page-layout directives. Both in principle and as someone who has used a few of these systems, i think they're fatally flawed for anything more than simple layouts. I know that we *can* accomplish elaborate layouts with such systems - god knows, i've done so. I'm just saying they're unnecessarily hard to unravel, change, and debug - because of an impedence mismatch, where the structuring of one syntax does not obey the structuring of the other. (Recently i posted something equating this intermixing of structural boundaries with undisciplined use of goto in a high-level language - both defeat many of the benefits of clean structuring. This sort of thing is especially galling, eg in DTML, to those of us that came to Zope with an appreciation of Python for its tendency to exceptionally readable, comprehensible code. I also like lisp, particularly for its elementary syntax and susceptibility to programmatic manipulation, but have been won over beyond lisp by python's economies...) Using XML for your language, as i gather HyperTIES does, avoids the structural disruptions, since XML is strict and consistent with HTML. By sticking with HTML, however, we also leverage pervasive expertise - at least being able to use the efforts of the numerous folk familiar with HTML, and in some cases enabling them to do various levels of their own programming hookup with ZPT. There may seem to be ways we restrict our templating language by using HTML, and in some ways, that's right. In fact, that's another, very important benefit, here. The Zope environment provides numerous ways to express elaborate business logic, ways that are much easier to read and process than any markup-oriented language can provide. (These ways include things like web-editable python scripts, standalone external methods, and product methods, as well as SQL methods and so forth.) Markup is best used for presentation - the only procedural logic we want in our templates should be presentation specific, or calls out to tap the results of the application business logic, underneath. Conversely, the business logic should not have to produce presentation - just provide the fodder for it. ZPT sits in this balance, very nicely i think. I haven't been following the conversation very carefully, so don't know whether or not you've gotten acquainted with ZPT - the canonical place is: http://dev.zope.org/Wikis/DevSite/Projects/ZPT Considering the approach of HyperTIES, you may find a lot to like there. -- Ken Manheimer [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Increased community participation in collectors
We've changed the Zope issue collectors so that any authenticated (logged-in) visitors can comment on issues, not just collector staff and the requester. This is all in the pursuit of quality information flow - some of you have asked for the ability to include your illuminating experiences and/or solutions to existing issues, now you can. Please be discrete with this - me toos can drown out crucial info. Currently, all the collector.zope.org collectors have authenticated-visitor commenting enabled: http://collector.zope.org/Zope http://collector.zope.org/Zope3-dev http://collector.zope.org/ZopeOrg http://collector.zope.org/ColDev Commenting in an issue does not subscribe you to the issue - that may be spiffy idea, but it'll have to wait for another day. -- Ken [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Utility of zope.org wiki page subscriptions
I'm finding the wiki page notifications mechanism extremely helpful for tracking wiki activity. While there's not much time available to tweak it further for people's needs, i'd like to collect feedback about how it does and doesn't serve other people's purposes, so that when we get around to the comprehensive effort we'll be able to factor-in that info! If you're using the feature and have comments, or not using the feature because of some shortcoming, please take a moment and add your comments to the effort feedback page: http://dev.zope.org/Wikis/DevSite/Projects/FishbowlNotificationsForNow/FeedBack If you're not using the feature because you don't know about it (what the heck am i talking about, anyway?-), see a copy of the announcement at: http://dev.zope.org/Wikis/DevSite/Projects/FishbowlNotificationsForNow/ReleaseAnnouncement (For those of you that missed that announcement and the subscriptions links, i think the feature is quite useful as is, and can significantly enhance the fishbowl process if it's used.) -- Ken [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] zope.org wiki tinkering
I'm going to be tinkering with the wikis on zope.org, to try installing my adaptation (and extension) of simon michael's wiki page change notifications to WikiForNow. I've exercised the changes as best i could on a separate site, and don't expect any disruptions, but the unexpected sometimes happens.-) I'll followup to zope-web shortly with details about the changes and help i'd like banging on them, once they're ready for trials, and then to zope-announce describing the new features once they're ready for wide release. I expect all this to be happening today, maybe stretching into tomorrow depending on the, well, the unexpected... -- Ken [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope collector is broken
I'm sorry, i'm unable to reprovoke the problem! Is there anything unusual about how you were submitting? Did you try more than once, to see if the problem is consistent? On Fri, 07 Dec 2001 11:43:52 -0500, Chris Deckard wrote: I tried submitting a new issue to the Zope collector at 11:42AM EST. Here's the traceback and error message: Zope Error Zope has encountered an error while publishing this resource. Error Type: WorkflowException Error Value: No workflow provides the request action. [...] WorkflowException: (see above) -- Ken [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope collector is broken
On Fri, 7 Dec 2001, Christopher N. Deckard wrote: I tried multiple times. I tried again this time, but deselected the security related checkbox. It went in. The issue _is_ security related, though not something that makes zope insecure. Aha! My fault - it had neglected a setting in the collector workflow. I've corrected that now - people should be able to submit new security-related items. I also set your issue to security-related. Thanks for reporting this, and the clues to track it down! -- Ken [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] How to report stuff with the collector down?
On Tue, 16 Oct 2001, Ken Manheimer wrote: On Tue, 16 Oct 2001, Andy McKay wrote: So what is going on with the Collector, its been what a month now? See http://dev.zope.org/Wikis/DevSite/Projects/CollectorReplacement/CurrentStatus for current status. In fact, i'm hoping to have something to test tomorrow. I've set up the new collector on new.zope.org, so anyone with an account there can create one and try it out. There are a few small (probably quick fix) but crippling bugs - most notably malfunctioning full-text search - which i don't have time to fix before leaving for some RR, so it's definitely not yet ready for prime time. I expect to get to them on monday, and have them solved soon after - and maybe people in the know will look at the issue collection i assembled in http://new.zope.org/Members/klm/ColDev and have some answers ready for me when i return...-) If you create a tracker of your own, you can try out the workflow - i'm pretty keen on what's possible with that kind of facility. For the whole picture, do a CVS checkout of the CMF and install the collector in a site of your own - there's an INSTALL.txt in the product directory with instructions. Visit the portal_workflow tool in your portal, and examine the collector_issue_workflow. Lotsa potential. Feel free to add reports of substantial bugs in the collector i mention above, as long as they're not mentioned in existing issues - which, in the absence of full text search, means scanning the existing ones... -- Ken [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Addressing client-side trojan problem
Shane Hathaway [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Personally, I think this really should be an integration issue instead of a Zope issue: use a front-end proxy server (i.e. Squid) and set up ACLs to prevent this... This hasn't been fixed because it's not well understood. Javascript can POST an invisible form, AFAIK. The problem occurs on the browsers of users who are *already authenticated*. It has nothing to do with Zope or any server software, really. I recently saw a _very_ interesting description of how capability-based distributed computing (and the Principle of Least Authority) is used to address vulnerabilities to client side trojans, viruses, etc. I think the approach may apply to the web situation. Capabilities are a signficant, fairly established idea in the realm of distributed operating systems, but are not very familiar more generally. This description is by far the most approachable i've seen (and perhaps, the first i've understood:) - i highly recommend looking it over. It's in a substantial overview of the very nifty looking scripting language, E, which is specifically designed to provide secure, reliable, manageable distributed computing scripting. The relevant bits are at: http://www.skyhunter.com/marcs/ewalnut.html#SEC41 A page or two down it describes the ramifications for things like computer viruses, if you want to skip straight to the punch. That part doesn't quite capture the way i expect we would use it to address the client-side trojan problem. Offhand, i suspect we could use these principles with Zope cookies and capability-specific roles. This approach provides a means for implementing something along the lines that chris petrilli was suggesting a while back, with incremental, rather than either/or, role privileges. Ken [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Fishbowl not problem centered enough
On Wed, 20 Jun 2001 09:24:40 -0600, Casey Duncan [EMAIL PROTECTED] 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? 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 know there has been talk of opening up the Zope CVS to outside contributions, I personally think this is long overdue. In order for a community development forum to really work, this would have to happen. This actually is high in our priorities, but the key players have been swamped. From a discussion w/paul recently i think we'll be getting some more attention to doing this, very soon. I just see lots of solutions many of which attack some of the same problems and no clear way to get those people comunicating and making informed trade-offs I think the fishbowl, as it is, is a good significant move towards exposing the process and enabling involvement. Mailling lists help conduct the collaboration. However, more is needed to facilitate that process - selectively enabling checkins, doing notifications to make tracking of developments manageable, fleshing out the context (problems/big picture). It's an incremental process, and we may have lapsed too long in progressing on those increments - perhaps we need to chart out some of these critical pieces, so we can better formulate how they're being attacked - and maybe enable more help with the increments. I hope to have expore this some, internally, and have more to say about it next week. Ken Manheimer [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: oodb philosophics ;) was: Re: [Zope-dev] Experiments withORMapping
On friday, 11 May, Joachim Warner wrote: The other motivations for an RDBMS are (1) people have existing schemas and want Zope to access the same data as their existing apps, and they want it to be transparent, and (2) tables with millions of entries are easily stored in Zope but the perception is that the catalog isn't as fast as a database index. No one has done any tests AFAIK. Then we should do these tests. E.g. I'd like to see: - 20 GB of Word and PDF documents stored in the ZODB and full-text + metadata indexed in ZCatalog - the complete [EMAIL PROTECTED] mailing list archive in the ZODB If Zope can handle those without the help of external tools (RDBMS etc.), I'll use it for all our Document Management ... As a matter of fact, we did a quick CMF demo that has the content of the zope list, zope-dev, and many of the other zope.org lists, and the comp.lang.python list for the past few years. The catalog searches are very very fast, i can't recall if the demo was set up with some interesting canned CMF topics, but the things works well. The picture isn't altogether rosy - the process of loading the objects was arduous. On the other hand, the exercise (actually, a subsequent one with simpler article objects) served as the basis for tuning the cataloging process, and may have helped it get a lot better. If i have time next week, i'll see if we have the corpus online somewhere. (The lists were complete up to a few months ago.) Eventually we'd like to be incrementally stuffing new messages into the database as they arrive. The catalog has required some substantial work investment, but from my viewpoint (particularly since i haven't had to work on it!-), it's well worth it. Actually OracleStorage and bsddbstorage, recently released, are designed to address concerns about performance and reliability, and they do an excellent job at it. And I consider ZODB as real an OODB as anything else. (In some ways it's the best out there IMHO.) Agreed. ZODB has a much longer proven history of success than most other OODBs. It is quite useful! I have no experience programming with other object databases, and very little with relational databases, so i have no basis for comparison. What i do know, as a python and zope programmer, is that ZODB is spectacularly useful as a persistent store - as flexible *and* as powerful as i could want. The addition of ZEO manages to significantly increase that usefulness! The work we/pythonlabs (and andrew kuchling, etc) is doing to enable use of it as an independent entity can only help improve it's usefulness for everyone. Ken Manheimer [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] PLEASE trim cited text!
I've been watching this for a few days now, holding back, but it's **awful**! *Please* take a few moments to extract relevant portions from cited text, definitely do *not* include the whole thing! (There is no excuse for multiple copies of the footer, usually not an excuse for a single copy.) For those of us that read via digest mode, at least in some interfaces, it makes increasingly hard to find messages. I'm taking the liberty to include one example just to demonstrate the ridiculous length this has gone. Ken Manheimer [EMAIL PROTECTED] From: "Andy McKay" [EMAIL PROTECTED] To: "Chris McDonough" [EMAIL PROTECTED], "Dyon Balding" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [Zope-dev] Tracking memory leak Date: Wed, 11 Apr 2001 09:35:16 -0700 If you're talking about ZSQLMethod options then its at the default which is Maximum results to cache 100 Maximum time (sec) to cache 0 Does that mean the first 100 results are being cached for ever? That might do it... Cheers. -- Andy McKay. - Original Message - From: "Chris McDonough" [EMAIL PROTECTED] To: "Andy McKay" [EMAIL PROTECTED]; "Dyon Balding" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, April 11, 2001 8:51 AM Subject: Re: [Zope-dev] Tracking memory leak Andy, Jim just brought something up... do you have database result caching turned on? If so, what is your number of max results to cache and max time? - Original Message - From: "Andy McKay" [EMAIL PROTECTED] To: "Dyon Balding" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, April 10, 2001 7:55 PM Subject: Re: [Zope-dev] Tracking memory leak Im not convinced its just SQLAlias though, I commented out the SQLAlias creations and I was still getting the other object refcounts shooting up... Cheers. -- Andy McKay. - Original Message - From: "Dyon Balding" [EMAIL PROTECTED] To: "Andy McKay" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, April 10, 2001 4:46 PM Subject: Re: [Zope-dev] Tracking memory leak i was one of the people that ran into big problems with that previous bug. if that is the one you are coming across, then the problem occurs when you try to access the data in a column using a dtml-var with a different case to what it is stored in your database. eg. if you have a column called ID in your database, and do a dtml-var id, then prior to the bug fix, you would see refcount increases for SQLAlias (and possibly some other types as well - can't remember too clearly). hope that helps you track it down -d On Tue, Apr 10, 2001 at 10:25:09AM -0700, Andy McKay wrote: I have the impression its not SQLAlias thats the problem since im also getting Record.Record, Acquistion.ImplicitAcquirerWrapper and Extension class floating around. I just commented out the lines that create SQLAlias instances and that was fine but... Sorry you're getting bugged here since you answered my first post. -- Andy McKay. - Original Message - From: "Chris McDonough" [EMAIL PROTECTED] To: "Andy McKay" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, April 10, 2001 9:59 AM Subject: Re: [Zope-dev] Tracking memory leak I believe it handles the translation of the sql fields from upper to lower and vice versa. More than that, I'm uncertain. - Original Message - From: "Andy McKay" [EMAIL PROTECTED] To: "Andy McKay" [EMAIL PROTECTED]; "Chris McDonough" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, April 10, 2001 1:01 PM Subject: Re: [Zope-dev] Tracking memory leak Any chance you could clarify what SQLAlias does, ive definitely got the case where some sql queries (and the way they are handled / used) causes an increase in the SQLAlias count and some dont. Id like to find the quick work around so I can get around to testing ZmxODBC Cheers. -- Andy McKay. - Original Message - From: "Andy McKay" [EMAIL PROTECTED] To: "Chris McDonough" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, April 10, 2001 8:55 AM Subject: Re: [Zope-dev] Tracking memory leak As far as I can tell those changes are still in. Do I understand them? Not really. -- Andy McKay. - Original Message - From: "Chris McDonough" [EMAIL PROTECTED] To: "Andy
Re: [Zope-dev] ZCatalog and 'fuzzy logic'
On Wed, 10 Jan 2001, Morten W. Petersen wrote: I do not think that "fuzzy logic" is strongly related to "regexp-like". Anyway. Fuzzy searching often means "finding matches with characters omitted, replaced or inserted". It seems I misunderstood the term fuzzy logic myself. Fuzzy logic means if I search for a word, for example 'programmer', it will return matches to the words 'program', 'programming','programmable' etc. I think your talking about something else. Last i checked, "fuzzy logic" was a logical algebra based on the existence of intermediate truth states, between "true" and "false". It has little or nothing to do with aproximate searching, though i guess you could use it to make assertions about the aproximations. I think what you all are talking about is "fuzzy matching". I.e., it will somewhat intelligently return words that are similar in what they mean, using grammar rules (chopping off endings of words and making them match others). There are also matching mechanisms like soundex, that account for misspelling by translating words to phonetic-equivalent normalized codes, and comparing on that basis. Ken [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope] Re: [Zope-dev] ZCatalog and 'fuzzy logic'
On Wed, 10 Jan 2001, Morten W. Petersen wrote: I do not think that "fuzzy logic" is strongly related to "regexp-like". Anyway. Fuzzy searching often means "finding matches with characters omitted, replaced or inserted". It seems I misunderstood the term fuzzy logic myself. Fuzzy logic means if I search for a word, for example 'programmer', it will return matches to the words 'program', 'programming','programmable' etc. I think your talking about something else. Last i checked, "fuzzy logic" was a logical algebra based on the existence of intermediate truth states, between "true" and "false". It has little or nothing to do with aproximate searching, though i guess you could use it to make assertions about the aproximations. I think what you all are talking about is "fuzzy matching". I.e., it will somewhat intelligently return words that are similar in what they mean, using grammar rules (chopping off endings of words and making them match others). There are also matching mechanisms like soundex, that account for misspelling by translating words to phonetic-equivalent normalized codes, and comparing on that basis. Ken [EMAIL PROTECTED] ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope-dev] RE: [Zope] ZDESIGN IDEAS = How to improve 'manage'?
[This thread should not be crossposted to both mailling lists. I'm following up to zope-dev, and will post a note to zope saying i did so. In general, please do *not* cross-post - it's almost never justified, certainly isn't in this case.] On Tue, 9 Jan 2001, Mohan Baro wrote: My view is that as a sysadmin, I rather give ZOPE superuser/manager the ability install products through ZOPE, rather than giving them access to the OS. The point is that giving web-access visitors the ability to install products inherently gives them total OS/filesystem access, with the authority of the account that is running zope. As things stand, you can give out web access *without* this OS/FS exposure - you're talking about eliminating the discretion. Another view I have is that I do not want my developers to think about which platform they are working on. This convenience will be at the cost of risk. If you're willing to take the risk, products that give filesystem and command access will give that to you. (Is local filesystem access what LocalFS does?) Zope shouldn't _force_ you to be exposed to that risk, just because some people want the convenience. ZOPE runs on a variety of OSes and each one of then have their own way of providing file/directory security (or no security win9x). Zope should rely on its own security for its products. ... overriding the discretion of the system administrators? Not proper. System administrators should have the choice - if they don't, they'll refuse to run zope in droves - and well they ought to refuse. Ken Manheimer [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] urllib not available in Python Scripts?
On Sat, 16 Dec 2000, Evan Simpson wrote:
From: "Itai Tavor" [EMAIL PROTECTED]
[...]
Sure. Since you've already got a MoreBuiltins module, that's probably a
fine place to put this. In MoreBuiltins/__init__.py (or a brand new Product
directory of your choice) put the following lines:
import urllib
urllib.__allow_access_to_unprotected_subobjects__ = 1
...and similarly if you want to declare other modules PS-importable. As of
2.3, the proper way to do this will be:
from AccessControl import ModuleSecurityInfo
ModuleSecurityInfo('urllib').setDefaultAccess(1)
I wonder whether that ought to be something like:
from AccessControl import ModuleSecurityInfo, ENABLE_ACCESS
ModuleSecurityInfo('urllib').setDefaultAccess(ENABLE_ACCESS)
?
The benefit of having an explicit name for "enable" is marginal, but would
become significant if there were other access modes besides ENABLE and
DISABLE - eg, "ENABLE_METHODS", "ENABLE_ATTRIBUTES", etc...
Ken Manheimer
[EMAIL PROTECTED]
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] A few corrupt files in Public CVS discovered and corrected
Recently (yesterday and today) we found a few files in the CVS repository to be corrupt - different than the internal CVS files from which they were mirrored. We've run a check to track down all such files, and have corrected them all. However, we don't know at this point whether or not the mirroring process, itself, is corrupt - we don't know whether this is a one-time or an ongoing problem. Here's a list of the files that have turned up - they should all be ok now, and an update of your checkouts should get the fixed versions - at least for the trunk. For branches, you should probably move aside your existing copies of these files (preserving changes) and do an update to refresh them from the rectified repository files. They are: zpasswd.py wo_pcgi.py z2.py inst/binary_install.py doc/FAQ.txt I've done a quick recursive diff of an internal and public checkout to determine that this is all of them, at least at the moment. Assuming my check was accurate, we'll know that we have a continuing problem if new ones show up - hopefully not, but keep a lookout, and let me know if you discover any more. (Thanks to shane and dyon balding for pointing out the problem.) Ken [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Turning acquisition off[Zope-dev] Turning acquisitionoff
On Wed, 6 Dec 2000 [EMAIL PROTECTED] wrote:
Does anyone know how to disable acqusition ?
That is, with a simple method, and not disabling the Acqusition class,
something like self.aq_disabled('attribute') .
I believe one way is self.aq_base['attribute']. aq_base gets the
unwrapped object (what got __of__'ed). If you're not sure the thing
is acquisition-wrapped in the first place, you'd probably want to check
for the existing of the 'aq_base' attribute before using it...
Ken Manheimer
[EMAIL PROTECTED]
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Turning acquisition off
On Wed, 6 Dec 2000, Chris Withers wrote:
Ken Manheimer wrote:
On Wed, 6 Dec 2000 [EMAIL PROTECTED] wrote:
Does anyone know how to disable acqusition ?
That is, with a simple method, and not disabling the Acqusition class,
something like self.aq_disabled('attribute') .
I believe one way is self.aq_base['attribute']. aq_base gets the
unwrapped object (what got __of__'ed).
What if the base object's not a dictionary?
I suspect i was missing something, but i assumed since he was referring to
an attribute of the object, that morten did not mean to write a function
call form. I probably should have presumed toward attribute lookup:
self.aq_base.attribute or getattr(self.aq_base, 'attribute') - and been
explicit that i was reading between the lines, in the first place.
If you're not sure the thing
is acquisition-wrapped in the first place, you'd probably want to check
for the existing of the 'aq_base' attribute before using it...
Am I imagining things of did Jim F say he might make ac_base present in
all the acquisition classes so that kind of checking isn't necessary?
Dunno.
Ken
[EMAIL PROTECTED]
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope Book Question: 'context' doesn't work in PythonMethods
On Mon, 20 Nov 2000, Shane Hathaway wrote: They are using an unreleased version of the Python Methods product. AFAIK the only thing holding up the release of the new Python Methods is the renaming. (I believe the version in question is available from the public CVS repository, as the Products/DC/PythonMethod module.) (Ken) [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Help! Can't unsubscribe!
On Fri, 17 Nov 2000, T.J. Mannos wrote: I'm trying to unsubscribe from this list because it's filling up my mailbox too fast. However, when I try to use the web interface or the e-mail interface to unsubscribe, it gives me an odd error message. It says something to the effect of, "There's something wrong with your account. Please contact the postmaster." Yet I keep getting zope-dev messages. Could somebody tell me how to get off this list? I've cancelled your zope-dev subscription. (We're running an old version of the maillist system, which occasionally has this problem - fortunately, we now have some people with the time and leverage to shepherd, fix, etc an upgrade to a newer version - will be happening soon. In the meanwhile, sorry about the capture!) Ken Manheimer [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] New proposal - WikiForNow
A week or so ago i threatened to post a proposal for near-term fixes of wikis on zope.org to alleviate some of the glaring fishbowl pain (looking to collect preliminary suggestions) - well, it's here: http://dev.zope.org/Wikis/DevSite/Proposals/WikiForNow From the problem statement: While wikis as they stand provide benefits for the fishbowl process, we've all been chafing under some shortcomings, some of which need to be rectified soon, to reduce chafing and increase scalability of the process to increasing numbers of items (proposals and projects)... Feedback is welcome, here in zope.dev and on the discussion page: http://dev.zope.org/Wikis/DevSite/Proposals/WikiForNow If you give feedback that has a conclusion here in zope.dev, realize that it may slip by the way until you register it in the discussion page. Conversely, if you respond there, please post a note here so concerned parties (including me) know to check them out. (This notification awkwardness is one of the things i think important to address soon, hence part of the proposal...) -- Ken Manheimer [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Cruft on dev.zope.org
On Mon, 30 Oct 2000, Chris Withers wrote: I went and had a look at dev.zope.org for the first time in a long time and noticed that there's now _lots_ of proposals which no indication of which ones are active/done/outdated/etc. I took off my cruft but I was wondering what the process is for ageing proposals and dealing with ones that are and aren't successful... It look like we're soon - within the next few weeks - going to have some time to devote to wiki/process. I'm going to try, within that time, to come up with a tactical proposal - for near-term measures to deal with the immediate problems, like staleness. Offhand, i'm thinking about a "status" field for proposal and project pages, which the owner sets, and which creeps towards staleness, the longer that the principles in the effort fail to touch the status setting. Other suggestions are welcome, with the understanding that we're particularly looking for expediency, at this point, since there are a lot of things to be rectified. While i'm talking about it, my current sense of high-priority needs is: - Really *really* simple commenting mechanism, for feedback about wiki pages. This is not a squishdot/confera/zdialogue or anything like that, just a form that puts attributed comments linearly at the end... (More elaborate mechanisms will come later.) - Attribution - responsible parties should be identified for each page, as should the comment authors, etc. - Expose change history (with differences) - so anyone can look at a page and see progressive changes, along with who made them. (In addition to obvious reasons, credibility of attribution, in context where editors could change other people's comments.) - Editing constraints - where page owner can easily say what roles can edit, comment, just read pages. - Change notifications - this is a biggie. Enable members to "subscribe" to pages, and obtain emailed notices when they change. If there are other features that seem critical, please mention them - no guarantees, the idea here is near term expedience, maximum results for minimum effort. In not too long we should be able to look at ways to leverage PTK, etc, and do wiking right... -- Ken [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Task, Job or Operation?
Huh. We're looking for something neutral, to connote code that runs in zope to do some business logic or similar effect. It should distinguish the language used to express the logic - perl vs python vs xslt, etc. I hate "script", but it occurs to me that the "-let" convention may be useful: Python Zopelet Perl Zopelet XSLT Zopelet Zope-specific, runs on the server, shows the implementation language, won't be confused with non-remotely-editable functions, methods, scripts, code in general. This is the first one with which i'm comfortable - but i may well have missed something. Ken [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope] 'Offline' mailhost
On Wed, 4 Oct 2000, Hannu Krosing wrote: Perhaps it would be better to solve this by configuring your sendmail (or other SMTP MTA) to be non-blocking, i.e. store-and-forward. This seems like a good idea. It makes it hard to get disposition status for the delivery in the transaction - but that problem is intrinsic to email communications, and probably best addressed by using the "sender" header (i think it is), so delivery failure notifications go to someone who needs to know about the failure. Even better - but lots more complicated: have the failure notifications directed to a program which queues the fact of the failure for the sending program to use. I haven't used it, but contemporary MTAs have catchall aliases, by which you can handle a pattern of recipients. Have the envelope sender fit the pattern, and encode the information about the program that needs to get back the failure information. I think this kind of architecture is necessary for comprehensive mail sending from zope, with delivery failure accounting, since mail sending is inherently asynchronous. Maybe you could just use mailman as MTA, greating temporary mailing-lists. This is also a good idea in principle, but would wind up being cumbersome. Mailling list "objects" are heavy weight components in mailman - each one having a list metadata and archive directory, mta aliases, etc. Plus, you may have to leave the list up until the last delivery is completed (successful or not). Better, i think, to adopt techniques and steal code from mailman, to take the pieces you want. Ultimately, i don't think you'd be taking that much - there's a lot in python that gets you a lot of the way. It's the embedded knowledge that's useful... -- Ken [EMAIL PROTECTED] ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
[Zope] Re: 'Offline' mailhost
On Tue, 3 Oct 2000, Chris Withers wrote: What, IMHO, is really needed is a mailhost/sendmail tag type thing that gets a message and a list of addresses to send it to. If it could do that in a seperate thread/process/whatever so that whatever calls it doesn't block, that'd be great. Of course, it'd need to have a 'hook back' method provided so any errors that occured could be dealt with. I wonder how mailman does this stuff and if the code could be borrowed for Zope? I don't have a quick answer. (It's been a long time since i worked on mailman, and this stuff in particular has changed a lot.) It looks like the code in Mailman/Handlers/SMTPDirect.py is what's of interest, and it doesn't depend too elaborately on the rest of mailman, which is good. I'm have no idea whether it solves the problem of doing unblocking delivery in a way that lets the delivery requester get a status back. Ken [EMAIL PROTECTED] ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope-dev] mailing list 'noise'
On Fri, 29 Sep 2000, Rik Hoekstra wrote:
Karl Anderson wrote:
I read the 2-10 articles that I'm probably interested in, and miss the
95% which is almost always noise.
The question is why you'd want to receive all this if you don't have to
(as remarked above).
As I understood it, the discussion is less about tools and more about
modes of discussion.
That's my impression, too. In fact, this would make a good case in point
- this is part of a rambling discussion originally about, as best as i can
tell, current wiki deficiencies for interactive discussions ("I feel your
Wiki Pain:-)"). Focus in this thread has moved to merits and deficiencies
of mailling lists for discussions - wiki is no longer the center in this
branch, the zope-dev list was for a bit, and use of gnus for effective
filtering of mailling lists is perfect fair game. I'm glad, though, that
rik brings back in the issue that really concerns me - modes of
discussion. I'm interested in what they serve.
In fact, i'm *really* interested in "turning answers into stories". That
is, not just getting answers to questions, but preserving them in a way
that makes them easy to find when they're next needed - organizing them so
they collectively serve to describe the topic they're about, to make the
topic, as a whole, discoverable. While i think there are many modes of
discussion that can serve this purpose, depending on the application and
collaborative context, i think mailling list discussion threads need more.
They're a step towards that building-together, but fail to organize beyond
that - so the answers they provide are fragmentary glimpses into the topic
at hand.
One key way wiki documents help bind the fragments is by providing more
"fixed points" around which discussions can range. The fixed points
are not immutable - they can evolve - but they're easy to point at, and
provide a definite manifestation of the topic at some stage of its life.
The dev.zope.org proposals site is one example where definite subjects are
at hand. As someone behind the WikiNG proposal, who *wants* to be able to
reap the suggestions and details from a discussion, but knows i won't have
the time for a while to actually concentrate attention on it, i dread
having to collect all the messages, for later review for harvesting.
Furthermore, messages on the mailling list tend to diverge more and
farther from the topic, than they do when placed within the wiki.
What i'd like the best, for now, is to have discussion happen on the
mailling list *when someone wants to feel something out*, *and then
they're responsible for summarizing in the wiki discussion page, if they
have anything to harvest*.
(Sorry if this message is a bit scattered - i think i saw an opportunity
to tie together a lot of thoughts i have on this subject, but not
sufficient time to do so cleanly, so i'm erring on the side of
just-throw-it-in...)
Ken
[EMAIL PROTECTED]
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] WikiDot
On Thu, 28 Sep 2000, Chris Withers wrote:
4.Some people think Wiki discussions are easily dispersed. Bad Wiki
discussions are, but discussion products are almost always dispersed by
nature. On many occasions I have (already) seen people summarize and
structure maillist discussions into a Wiki web.
Yes, but does that mean the Wiki is good for the initial discussion?
The point you've cited seems to be about something else (why wikis can
work for discussions, not why they're good for setting them up). My
response to your challenge is that the lack of a clearly designated
document or other artifact as the focus of a discussion can, and, i
think, usually does, lead to drift in the discussion. In weblogs, the
document at the top anchors the discussion. In our proposals site,
the proposals serve as (evolving) subjects of the discussion.
I don't think anyone disagrees that wiki pages as they stand are
imperfect for discussions. I strongly feel (with lots of experience)
that mailling lists are also flawed, sorta complementarily, for
getting definite results out of discussions. Both work with some
effort, i think many of us feel that a insightful hybrid could reap
more than the benefits of both.
The Wikis on the
dev.zope site do a bit of this with delegating discussion to a
discussion
page.
Yes, but that's only advisory, it's not enforced...
What's your point? It seems to work, though there's possibility for
it to breakdown. We recognize that possibility is significant, and
would like to address it - hence the WikiNG proposal, and many other
expressions of desire to fix these sorts of things. Actually, we're
sorely chafing under lack of such fixes, but we can't afford to
neglect our other commitments (clients, including zope community!) at
the moment to do so. And we feel that we're better off, for the time
being, with fixed points as the focus of proposal discussions, for
instance.
Most of these points are addressed in the proposal, but what I wanted to
add is the notion of the necessity of integrating the three types of
discussion into one product. That would make for a new generation. How
would that look then:
snip Memepool equivalent
Funny you should say that. Some other people I'm chatting to have come
up with roughly the same ideas...
We discussed (in a off-list discussion) a point of karls, that the
tracker and weblog can map onto eachother, with some structural
provisions. I can see something very similar with wikis.
(This came out of a discussion with ethan - we were wondering how the
WikiNG stuff fits in with the PTK. We came up with a bunch of stuff
that i really like, including this vision of integration with
s{qu,w}ishdot - just a concept, to demonstrate the kinds of things
that would be possible - i'm not looking to impose it on you if it
doesn't seem suitable to you.)
A weblog could constitute a wiki space, with the topic message being
the FrontPage and the threads hanging off of it being nested wiki
pages. The discussion pages would automatically get names, per their
nesting status - LogSub1Sub2 or something, overridable by the page
author to have semantic significance. The benefits:
- Structured text.
- Easy for authors to refer to other messages in the discussion by
name, using wiki references.
- Wiki organizational features - table-of-contents view, ability to
adjust nesting situation in the discussion (modulo the weblogs
policy - often the owner may disallow any such adjustment, but in
some cases it would make sense).
- With WikiNG's prospective notification mechanism, people could
"subscribe" to email notifications for any changes - additions,
edits, etc - within threads/subthreads, or just for additions at
top levels of threads. The latter is like "executive summary"
monitoring, wanting to know only when the uppermost parts of the
discussions change, without having to worry about changes to the
outlying parts of the discussion tree.
- With email-in wiki pages [i have to comment on mj's proposal, i
have similar ideas in the WikiNG proposal, but haven't had time to
evaluate his specifics!], people could use their subscriptions to
hierarchies within the weblog to make their contributions via email
- often for submitting new messages, but perhaps sometimes for
annotating existing ones, a la...
- With WikiNG editing policy control, the weblog *could* have a
policy that allows authors to amend their messages - eg, to insert
or append comments to their existing messages. Or to edit their
messages, if that fits the task at hand. (Eg, if what they're
doing is collaboratively developing a document.) The basic case
would not allow this, for more classic, conventional weblog
conduct.
Lots of good stuff. The essential thing in this perspective is seeing
the weblog as a structured viewing mode for the contents of the wiki -
or the wiki as being an substrate for the
Re: [Zope-dev] mailing list 'noise'
On Thu, 28 Sep 2000, Chris Withers wrote: Toby Dickenson wrote: I dont see this as a problem: You only create a new list when the traffic for that proposal gets too great for zope-dev. Threading is good enough before that point. Yes, but zope-dev has a relatively high traffic load... Why should you have to put up with all that 'noise' if you're only interested in posts for your comparatively small discussion? Yeah - maillists flow by, and not everyone can follow all the traffic all the time!! The cool thing about "content-based" mailling lists, where people can subscribe to notifications about changes in subthreads, is that you just subscribe to the part of the discussion that has your interests!! -- Ken [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] WikiDot
On Thu, 28 Sep 2000, Chris Withers wrote: These are the kinds of things i'm hoping to get at with WikiNG - a smart content widget, with two essential features - good impedence matching to authoring structured, linked content (structured text plus wiki refs), A lot of people I know would disagree with the Structured Text bit, but I guess it'll have to do for now. Wysiwig editing on the web hasn't arrived yet :-( (I wonder whether having a single quick ref page for structured text, linked to on every edit form, would go a long way to reducing those objections. Particularly if the quick ref page is clear and concise.) and intrinsically determined and easily adjustable organization. 'Easily adjustable' could be difficult... I was just referring to the ease of reparenting a page - if this isn't familiar to you, see the backlinks pages in any zope.org zwiki. Ken [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Email the changes
On Thu, 28 Sep 2000, Chris Withers wrote: The only quoting you need to know is example:: The two colons after the word "example" indicate that this contained block is all quoted. How is a 'contained block' delimited? As i did in my example, by indentation. (This is a primary component of the "structure" in StructuredText. Maybe we're not being clear enough about that in our explanations of structured text - i would expect that not knowing about it could make it much much harder to understand what's going on, in general, with StructuredText!) Ken [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Discussion Story Building Mediums
*This message was transferred with a trial version of CommuniGate(tm) Pro* On Fri, 15 Sep 2000, Chris Withers wrote: Ken Manheimer wrote: Convenient for what? If you've ever tried to support a community through a mailling list, you'll quickly notice that questions, and their corresponding answers, repeat. A lot. The problem is that while maillists are great for keeping people up-to-date on the business of the community, and for disseminating dialogue, they are not so good for building structures - for organizing content so related pieces of a story are appropriately connected. The counter that this is that Wikis, in my experience (and maybe mine only ;-), are not a good medium for discussions. There's no threading, notfication or subscription, for starters... Clearly, i agree that the absence of those things in the wiki is a problem - i state that directly in the "problems to be addressed" section! *The* thing to understand here is that we're currently in a position where neither wikis nor maillists, in themselves, provide what we need. We need to do *something* in the meanwhile, if only to bootstrap the process so we can get to the point where we have that integration. (You'd have to ask brian and the dev folk, but i think the reason we're going with wiki is because otherwise all this talk gets **lost** - noone has the time to do the transcribing, etc. At least with wikis you can preserve your thoughts and then email interested parties!) My proposal is all about getting there - i yearn to get the time to do some of what's necessary - at least ZClass-ification so i can do the notification stuff in a clean way, because we're suffering without notification - and i'm hoping there will be a window in not too long. I think this discussion is evidence of the need, not of flaws in the proposal! Wikis, as they stand, are not bad for organizing stories. ..agreed, but a lot of Wikis are not being used for this. It's a difficult problem. You need a decent medium for discussion, like a mailing list, which needs to automatically (and that seems _very_ hard to me) extract the necessary 'story' bits and store them in a decent story-building medium... Yes - it seems _much_ easier to me to have people annotate the existing wiki (restricted, perhaps, to only adding text, not changing existing text - that's easy to implement, though we'll have to go to some effort to make it user friendly). From the WikiNG proposal: For discussion, i can see two applications of a wiki document option that allows commentators (non-authors) to only add text, not change existing text. (Zope would diff the new revision and reject it if it contains changes to existing text.) Simplest application would be accepting changes only at the end - weblog style. Next simplest would be one that allows insertions anywhere, for comments next to subject lines. (Zope could offer readers knobs for controlling visibility of annotations.) The document authors could have the privilege of editing any text, to consolidate and refine. Both applications would be useful for different kinds of discussions. Wouldn't that be cool - with notifications to interested parties, perhaps including diffs that showed the annotations, and a bit of context? (A further alluring step would be to allow notification subscription options for getting the entire changed document, and enable the email recipients to add their annotations in standard email-citation style, and send them back to zope, for it to incorporate the edits. But that would take some authentication provisions, as well as better email integration...) We all sorely miss change notifications and ownership attribution, a preview button, etc - but they're better, even as they currently stand, for building longstanding artifacts than are mailling lists. And hopefully, in not too long, we'll be able to improve them, or provide something else, to do the job right. Well, the WikiDot idea is starting to crop up in my brain a bit more now ;-) And since that'd be a Swishdot skin, it'd work with the PTK, and everyone's happy and focussed on what they want to be :-) Well, this is, tangentially, a particularly interesting point for me. I've been challenged with how to fit the WikiNG proposal into the PTK - since the PTK is a prime digital creations content management focus, management doesn't want to dilute resource assignments with other (eg, WikiNG) content-management-oriented efforts. So i have to figure out how it would fit in that frame work - maybe this suggests a way. I'm having trouble fitting my mind around it, though. Sigh. Ken [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.o
RE: [Zope-dev] I feel your Wiki Pain ;-)
*This message was transferred with a trial version of CommuniGate(tm) Pro* [I'm running out of time here, so pardon the brief responses. Make no mistake, though - i'm glad to be having this discussion! It's good to be getting this input, seeing suggestions for other ways to look at this discussion problem...] On Fri, 15 Sep 2000, Toby Dickenson wrote: I dont actually have anything against Wikis in general; I have used on very successfully for what I would describe as "document refinement", and a better annotation scheme will enhance that use of Wikis. The passage you quoted uses terms like "subject document", and at the moment I dont see that as the best model for a *debate* Do you feel that weblogs are bad models for debates? I think they're pretty good least-common-denominators. I would probably prefer the kind of annotation-based thing i described in my last message (and began to sketch in the WikiNG proposal) for collaborative generation of documents, but i can see the place for weblogs, just as i can see a place for network chats. With adequate integration of email (for notification and response), i see them as better than just email... The ability to subscribe for notification (above) and/or to track what you personally have seen, and not, is intended for this kind of thing. It would keep me happy if the notification includes a link to the new content (rather than a link to the page that contains new content). Even better, the email notification could *include* the new content. Different options for different purposes - but we need at least notification! But Wikis don't (for me, today) work for loosely structured commentry. Quoting from http://dev.zope.org/Fishbowl/Introduction.html In some cases a mailing list will be setup for substantive, large-scale projects. Otherwise existing mailing lists can be leveraged (for now, use zope-dev for this). Perhaps I should rephrase my objection. The *real* problem is that this isnt happening - discussion is stored in Wiki pages like http://dev.zope.org/Wikis/DevSite/Proposals/XxxxDiscussion I think we all agree this is a problem. We seem to have found a short term solution - though i'll tell you that with time constraints, i won't immediately have time to incorporate the points raised in the documents. Ken [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Wiki Pain
On Thu, 14 Sep 2000 [EMAIL PROTECTED] wrote: Since the beginning of this year DC have moved alot of debate and discussion out of mailing lists, and in to Wikis. http://www.zope.org/WikiCentral/FrontPage lists most Zope Wikis. Does anyone else find Wikis to be far less convenient than a good old mailing list? Convenient for what? If you've ever tried to support a community through a mailling list, you'll quickly notice that questions, and their corresponding answers, repeat. A lot. The problem is that while maillists are great for keeping people up-to-date on the business of the community, and for disseminating dialogue, they are not so good for building structures - for organizing content so related pieces of a story are appropriately connected. (Note that i do *not* dislike mailling lists - before i joined DC i resurrected mailman from an abandoned prototype and developed it for use on python.org, because we needed a customizable system for conducting the ongoing business of the python community. Maillists just are not right for building structures.) Wikis, as they stand, are not bad for organizing stories. We all sorely miss change notifications and ownership attribution, a preview button, etc - but they're better, even as they currently stand, for building longstanding artifacts than are mailling lists. And hopefully, in not too long, we'll be able to improve them, or provide something else, to do the job right. (I am not hopeful about the fate of the WikiNG proposal right now, the powers that be are dictating that the PTK should be the medium for this kind of thing - and i don't see how to fit the low-impedence features of the wiki in there, and so will be severely disappointed if WikiNG doesn't fly, but that's up to others. In any case, *something* is clearly needed - the wikis are just the best fit for part of the job, right now.) Ken Manheimer [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] WikiDot? ;-)
On Thu, 14 Sep 2000 [EMAIL PROTECTED] wrote: Chris McDonough wrote: A lot of the listed complaints are trying to be addressed by the "WikiNG" proposal, which is (of course) in the Proposals wiki on dev.zope.org. The irony ;-) This may be a good idea... personally, I really don't have much of a problem keeping up with the discussions, but it seems a lot of people do. This idea should probably be floated in dev.zope.org itself as a proposal. I'll give it a go :-S How abotu a cross between a Discussion Forum and a Wiki? This is what i tried to get at with the part of the proposal about tailored structuring of wikis. Append-to-end structuring for weblog style wikis, allow-only-nesting (not-editing-of-other-peoples-stuff) for more elaborate structuring, etc. Structuring to the purpose, while exploiting wiki features, could be cool. If it ever gets a chance to happen, sigh. Ken Manheimer [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] pdbtrack.el - track source file whenever runing pdb in an emacs buffer
I've put together an alternative, pared down approach to doing python
debugging inside emacs - pdbtrack:
http://www.zope.org/Wikis/klm/PDBTrack
Once loaded, pdbtrack watches your (comint) process interaction
buffers for the pdb stacktrace. When it sees it, and can find the
file containing the current stacktrace focus, it pops the file up in a
separate emacs buffer, centered on the current debug line. This way
you continue to interact with pdb, stepping into and out of functions,
moving up and down stack frames, anything that changes focus - and
emacs displays the right place in the source in a companion buffer.
Of course, pdbtrack works just fine with the zope interactive debugger
(reachable, for example, via:
% cd $SOFTWARE_HOME/lib/python
% python
import Zope; app = Zope.app()
Zope.debug('Zope.app().whatever', d=1)
[debug...]
)
The big difference between pdbtrack.el and pdb.el is that you don't
need to start your debugging session in a GUD (Grand Unified Debugger)
buffer. I often have to arrange a lot of state in the interpreter
before i can jump into debugging. This generally defeats switching to
a GUD session, with its separate process - while pdbtrack just jumps
in whenever i go into the python debugger, within the accumulated
context.
pdbtrack lacks a number of things that GUD does have. It doesn't
highlight the current source line other than centering it in the
source buffer, and it doesn't provide nicities like stepping and
setting breakpoints from within the source buffer.
However, pdbtrack is much much more lightweight than gud - and it
might be interesting to see about providing some of the gud features,
like debug keybindings in the source file buffers involved in the
debug session, with this more open, decentralized model.
In the meanwhile, pdbtrack goes a long way towards doing what i want -
i hope it's useful to others. I've submitted an entry for vaults of
parnassus, not sure how long it takes to show. To repeat from above,
you can find it at:
http://www.zope.org/Wikis/klm/PDBTrack
Ken Manheimer
[EMAIL PROTECTED]
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope] Linking to Mailing List Managers - Mailman and Zope
On Thu, 1 Jun 2000, Nils Kassube wrote: Zope/E-Mail integration is something I'm very interested in doing as part of my CS studies (What's the English word for "Studienarbeit"?). However, my todo list of non-commercial projects is full, so it's probably going to take some time to do something that's not paid for, sigh, I should spend some time looking for companies here in Lübeck or Hamburg open for new technology which is not based on Java... With management via Zope pages do you mean something like the administration pages of GNU Mailman (written in Python)? http://www.gnu.org/software/mailman/mailman.html http://www.list.org One of the first things zope exercises i did when learning zope, not tool long after coming to digital creations, was create a product that hooked up with the Mailman installation on zope.org. (One of the last things i did at my prior job, at CNRI, was to resurrect and revitalize the prototype Mailman, for use as the maillist manager on python.org.) I moved on to other things, and the MMRoster product may be way out of date - i don't even know if the mailman interfaces have changed from underneath, and i *know* that the zope ones have - but the product still may offer some useful clues about one way to hook up with mailman. I just uploaded a tarball of it to my members folder - see http://www.zope.org/Members/klm/MailmanStuff/MMRoster.tar.gz (I know ethan is interested in this topic, and barry warsaw, mailman's current maintainer and my old colleague/buddy, has also expressed interest, so i'm cc'ing them.) All this said, i'm spread too thin at the moment to be able to *do* much more than watch, maybe chime in, if stuff happens... Ken Manheimer [EMAIL PROTECTED] ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Higher Education
On Fri, 26 May 2000, Timothy Wilson wrote: On Fri, 26 May 2000, Rik Hoekstra wrote: How many are still interested in this? I was among one of the first to be active in the zope-edu list and I am still interested and even working on a product for course maintenance. I even sent Shane an immature snapshot, but had to reimplement the product because of nesting ZClasses (sigh). Moreover, I was changing jobs as well, which did not exactly help in getting things from the ground. So - yes I'm still interested Shane. I'm still very much interested in this. School's out in a week or so, and I plan to work hard this summer worked on developing Zope stuff to be used here at school. I would love to renew the discussions. You know, there's the python edu-sig (http://www.python.org/sigs/edu-sig) - i wonder whether there's some point in crossing over the efforts? On the plus side, there's a number of educators there with real interest in teaching programming in a good way, on the minus side, their charter is pretty much python oriented, and zope may be a more narrow context than they would wish to dwell within. I mean, i'm not sure how the slightly different agendas would work out... Ken Manheimer [EMAIL PROTECTED] ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Re: [Zope-Annce] ANN: Perl For Zope - why I'm bummed
On 25 May 2000, Roman Milner wrote: Well, my point is that I don't think you will be able to ignore it. Your boss will give you a product to maintain that includes someone else's perl code - sooner or later. Since it is "part of zope" and you clearly "know zope" you should be able to maintain it. I'm not talking about maintaining zope itself. I'm talking about maintaining web sites that use zope. I have some misgivings with this outlook. It sounds like people who seek job security by having expertise with a system that closes out unfamiliar options - whether the options are better or worse. For all of you that love Python, and testify to either leaving perl with great relief or not being willing to learn it in the first place - why don't you trust your judgement? Python *does* offer better a better foundation for persistence, acquisition, general object-oriented applications, etc - you should not be frightened of a level, open zope playing field that admits both python and perl! If you don't feel python is better, just what you prefer, then you should be happy to have the additional power of perl (and it's community) available to you without having to leave your favorite language! It's a win in either case. (And zope will never be an entirely level playing field, because python and C *will* continue to serve as the foundation for Zope. Oleg, your refutation of that has the smell of casting Fear, Uncertainty, and Doubt - treating digital creations with some serious and, i think, unwarranted disrespect, if i may say.) I also think these objections are contrary to one of the principle reasons that python itself is so attractive - it's a glue language, after all. It enables people to use facilities from other languages, without having to get their hands dirty with them. I never really learned C - but that doesn't mean i won't use other people's C extensions! Many many people have found Python to be the best way to get acquainted with Java, with jpython - and i wonder how many java folks got turned on to python's advantages, though the ability to use java interactively via jpython. Access to other languages via python isn't a problem, it's a solution - why should it be any different with Zope? Personally, i suspect that it's much less likely that someone will switch from python to perl than the reverse, perhaps a sign of my own python bigotry - but if you're similarly inclined, once again, i think you should appreciate the advantages of this new open door. Ken Manheimer [EMAIL PROTECTED] ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Re: [Zope-Annce] ANN: Perl For Zope - why I'm bummed
On 25 May 2000, Roman Milner wrote: "KM" == Ken Manheimer [EMAIL PROTECTED] writes: KM I have some misgivings with this outlook. It sounds like KM people who seek job security by having expertise with a system KM that closes out unfamiliar options - whether the options are KM better or worse. I'm not in any way unfamiliar with perl. If this had been a language that I didn't know or, or any technology that I didn't know - I would have an opened mind. I've been down the perl road, and have made a personal choice never to do it again. I should have used "unwelcome" instead of "unfamiliar" in that sentence - i tried to say that in a number of ways, eg: Me For all of you that love Python, and testify to either leaving perl Me with great relief or not being willing to learn it in the first place [...] I think that anyone who wants to claim Zope expertise will need to know and be willing to code in perl. I dunno. There may be some Zope jobs where knowing perl would be necessary, but there may also be some jobs where knowing XML, SQL, XLST(?), WebDAV, the ZODB, SSL, LDAP, Oracle, medusa, C, *all* sorts of things would be necessary. Maybe you're proficient with all those things - i'm not! The thing is, Zope is an extensible ORB whose primary purpose in life is to connect disparate things together - you shouldn't need to be proficient with every aspect of it, in order to have mastery with it. I guess i can understand being uncomfortable with seeing a transition from a somewhat closed, very attractive (python) world to a more wide-open one that includes less attractive elements. Nonetheless, i really think this ultimately means that your zope skills are going to be more valuable, whether or not they include the perl aspect, because zope as a whole will have wider acceptance, a firmer place in the world. (Do you think the perl folks are, conversely, going to feel they have to know python? I have to say, i esteem python enough to think that the ultimate result will be increasing prevalence and preference for python.) Ken Manheimer [EMAIL PROTECTED] ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
