[Zope-dev] Re: [Zope-Coders] July Bug Day Roundup

2004-07-31 Thread Ken Manheimer
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

2004-07-30 Thread Ken Manheimer
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

2004-06-24 Thread 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.

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

2004-06-24 Thread Ken Manheimer
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

2004-06-24 Thread Ken Manheimer
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

2004-06-24 Thread Ken Manheimer

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)

2004-06-23 Thread Ken Manheimer
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)

2004-06-23 Thread Ken Manheimer
Most of the keys were not moved - i'm copied them, and you should now be 
good to go.

On Thu, 17 Jun 2004, Tim Peters wrote:

 [Ken Manheimer]
  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). ...
 
 At 9:10 PM EST, I still can't get in.  Did the ssh public keys get moved?
 Trying to update any of my writable checkouts via CVS yields Permission
 denied, as in:

___
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

2004-06-22 Thread Ken Manheimer
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)

2004-06-21 Thread Ken Manheimer
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

2004-06-17 Thread Ken Manheimer
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)

2004-05-28 Thread Ken Manheimer
[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

2004-05-07 Thread Ken Manheimer
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

2004-05-07 Thread Ken Manheimer
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?

2004-05-07 Thread Ken Manheimer
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

2004-05-07 Thread Ken Manheimer
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

2004-05-07 Thread Ken Manheimer
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

2004-05-06 Thread Ken Manheimer
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

2004-05-06 Thread Ken Manheimer
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

2004-05-06 Thread Ken Manheimer
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

2004-05-06 Thread Ken Manheimer
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

2004-05-06 Thread Ken Manheimer
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

2004-05-03 Thread Ken Manheimer
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)

2003-03-02 Thread Ken Manheimer
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

2003-01-21 Thread Ken Manheimer
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

2002-07-17 Thread Ken Manheimer

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

2002-05-16 Thread Ken Manheimer

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

2002-02-22 Thread Ken Manheimer

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

2002-01-15 Thread Ken Manheimer

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

2001-12-13 Thread Ken Manheimer

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

2001-12-07 Thread Ken Manheimer

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

2001-12-07 Thread Ken Manheimer

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?

2001-10-18 Thread Ken Manheimer

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

2001-09-25 Thread Ken Manheimer

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

2001-06-20 Thread Ken Manheimer

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

2001-05-11 Thread Ken Manheimer

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!

2001-04-11 Thread Ken Manheimer

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'

2001-01-10 Thread Ken Manheimer

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 )




Re: [Zope-dev] RE: [Zope] ZDESIGN IDEAS = How to improve 'manage'?

2001-01-09 Thread Ken Manheimer

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

2000-12-16 Thread Ken Manheimer

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

2000-12-07 Thread Ken Manheimer

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

2000-12-06 Thread Ken Manheimer

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

2000-12-06 Thread Ken Manheimer

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

2000-11-20 Thread Ken Manheimer

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!

2000-11-17 Thread Ken Manheimer

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

2000-11-03 Thread Ken Manheimer

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

2000-10-30 Thread Ken Manheimer

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?

2000-10-23 Thread Ken Manheimer

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-dev] mailing list 'noise'

2000-09-29 Thread Ken Manheimer

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

2000-09-28 Thread Ken Manheimer

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'

2000-09-28 Thread Ken Manheimer

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

2000-09-28 Thread Ken Manheimer

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

2000-09-28 Thread Ken Manheimer

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

2000-09-15 Thread Ken Manheimer

*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 ;-)

2000-09-15 Thread Ken Manheimer

*This message was transferred with a trial version of CommuniGate(tm) Pro*
On Fri, 15 Sep 2000, Rik Hoekstra wrote:

 ironyAt the WikiNG discussion page I wrote the following remarks, that
 I think not everyone will read/irony

(The territory is just ripe for irony, because we're talking about
developing tools for conducting collaboration - including these kinds of
discussions!  I *really* appreciate that you put your comments in the wiki
discussion page, and sent them to the list - i periodically check the
discussion page for developments, but i lapse, too, and generally find it
painful that i may wind up missing stuff.  I think the best model, now, is
to make changes and to notify people that they were made via this list -
as you've done.

(Not sure that will scale, but creating new lists for each proposal
definitely won't scale.  For a bit of nested irony, if i had time to do
some more mailman-connected work, i might make it easier to create
maillists - but i'm convinced that "content-based mailling lists" are a
much better solution to the problem - eg, that's part of what i'm aiming
for with WikiNG, and i'd rather spend whatever time becomes available on
that then on tweaking the maillist side of things.))

 Make the wiki the central/anchor point for discussion. This means there
 should be a possibility for making central pages, spin off pages and
 discussion pages. 
 - Wikis should be moderable on all levels (not editable, changes only
   after approval, free for all). The point up to which that is done is up
   to the owners/maintainers of the Wiki. 

Yes, this is something i also advocate, as you probably realize i did so
in the proposal.

 - Include both a (threaded) discussion product for discussion. 

I have to think about it more, but offhand i much prefer more tightly
coupling the discussion with the wiki content - make the "threading" based
on changes to the wiki, and if weblog style is called for, use wiki
structuring that restricts changes to the end of the existing
content.  (With allowance for having people with edit privilege that
allows them to consolidate...)

The thing is, if we had an annotation style wiki, where people are
restricted to insertions, but anywhere in the text, and notifications
indicated the changes, then the job of the consolidator would be **much**
easier - all the editors would be involved in organizing their comments in
the context of the document, as well as referring to relevant existing 
passages.  I would expect this "closer coupling" to promote more salient
collaboration - because people would have the burden of finding where
their points fit, in the process uncovering points they might have missed
if they just appeneded their comments to the end.  By offering a view that
shows the growth of a document, people can discern what's changed since
they last grokked the whole thing, and as easily as possible keep track of
the whole thing.  

Note that there's been a *number* of places in this recent WikiNG
discussion where' i've cited existing passages that directly address
people's points.  I don't mean to complain - i think that's one cost
increased by disconnecting the discussion and the document. I may be
presuming too much, but i strongly suspect that if we were all making our
points directly in the relevant context of the document, the reiteration
would be necessary a lot less often - or structural flaws in the
organization of the document would be exposed.  It's this aspect of
"building the stories" together where WikiNG ahs incredible promise, to
me.

 - Make this discussable from the web and from email. In the case of web
   discussion the advantages
   would be that discussions could take the form of annotations with a
   discussion. In the case of a maillist discussion this would mean
   instantaneous discussion. It should be possible to indicate in your
   email whether you want it included into the Wiki.
 This would also mean that there should be a structured way to integrate
 e-mails into a Wiki. The noding proposals (divide a wiki page into
 information nodes) above could well help to enable hooks for
 discussions. Perhaps even for determining which parts are discussable
 (namely only the one with a discussion node attached)

See my prior message on this subject.  I do think these are great ideas -
hope i'll get time before the end of the weekend to visit your comments in
the wiki discussion so i can include my responses.  If only the wiki took
care of this for us!-)

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] I feel your Wiki Pain ;-)

2000-09-15 Thread Ken Manheimer

*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

2000-09-14 Thread Ken Manheimer

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? ;-)

2000-09-14 Thread Ken Manheimer

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

2000-07-16 Thread Ken Manheimer

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 )