[Zope-dev] Open Letter to zope-dev
Since I seem to be the cause of all hell breaking loose over here, I thought take the opportunity to respond, since I haven't really been given an opportunity to do that. Since this probably going to be my only ever posting to zope-dev, I don't feel constrained to be brief in exercising my right of reply. I'm not going to apologise for the comments I made, or the manner in which I made them. Those comments were made on a list run by me, basically for my own amusement. If I had posted either of those emails to someone else's list, I'd quite rightly deserve to be fried. I don't make money from Zope Development (I don't make money), I don't run a website, in fact, I don't actually use any of the products I have released. So it's not like I have a vested interest in Zope. My fortunes don't rest on the success or failure of Zope or any one of its components. I live in a country the size of the USA that has the approximate population of New York State. Even if I stood on a busy street corner with a loud hailer, the number of people I could actually influence would be small. This makes me one of the people in the trenches. It is the people who are in the trenches who are increasingly being disaffected by Zope Corp, it seems as if you're not subscribed to zope-dev, you have no voice, and for most people zope-dev is not an appropriate forum for them to be subscribed to. As some of you know, I was hounded off of the zope@ mailing list for suggesting that there be some other mailing list for more technical discussion. People were very upset, because, they already have a hard time getting any support. Noone from Zope Corp seems to monitor the list to help out. The zope list was manned by people like me volunteering expertise and time to help more of the little people. A lot of those people come to the irc channel, which is also rarely if ever visited by anyone from Zope Corp. Most people know that #zope is the place to go when all else fails. The major irony of this is, that most of the people seeking help on #zope are working with it, or consulting with it, and are supported by me and others for free. We are the ones that deal with the 'general zope public.' We are the defenders of the faith. The Zope Weekly News, which turned into Zope Monthly News, which now has not been updated since October is a joke. It shows Zope Corporation's attitude towards their community. It says "We don't care about our community." I'm sure that's not the feeling of the *individuals* inside Zope Corp, I'm sure it is (or I hope it is) a source of great embarassment to those individuals that work for Zope Corp. Letting your community showpiece atrophy doesn't show any great passion towards us, it certainly doesn't endear new users to Zope. New users are the only way Zope Corp is going to make more money, unless of course zope.org is just for us non-revenue generating little fish, an inconvenience associated with having Open Source software, not something that promotes and supports the non-paying community. Noone wants a standardised User Management API more than me. I *want* to have confidence that someone can replace any User Folder with XUF, and it will just work. So when I come across something that says there is a New User Management API, I get excited. I prepare to roll up my sleeves and make the necessary changes to make software I contributed to the community continue to work. I think we all know by now my opinion on what I found, the harshness of the expression of that opinion is directly related to the way that these days Zope Corp seems to be an Ivory Tower and the way they seem to treat the community at large. There are approximately 450 products released by just over 200 people on Zope.org. There are approximately 1000 'entities' subscribed to this list (more to the main list), I represent 0.1% of this community, but, am responsible (but, not soley) for 3% of the total product space available. If people want to form an opinion of me based on one email, that's your right. You don't have the right to tell me, that *I* don't have the right to say the things I'm saying. I have earned the right to make these comments, I have contributed time, effort, and code, and I put my money where my mouth is. I'm not some backseat political observer, I am in the trenches I deal with the disaffected, the confused, and the generally pissed off every day. In my efforts, I try to help to make Zope a better product. You would be hard pressed to find a more stalwart supporter of Zope than me. This doesn't mean that I have to think that everything that leaves the holy temple of Zope Corp is the panacea of web development. My opinions might be wrong, but, they're not wrong simply because something was released by Zope Corp, or written by some person you have attached some god like status to. I will continue to do my thing, but, the way Zope Corp deals with us, the little fish had better change, or there's not going to be much of
Re: [Zope-dev] Searching/Indexing/ZODB/SQL/BerkleyDB
There are also set objects like OOSets and IISets that can be used in intersection and union operations as documented in the BTrees module. - Original Message - From: "Jeffrey P Shell" <[EMAIL PROTECTED]> To: "Matt Hamilton" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Thursday, November 29, 2001 12:18 PM Subject: Re: [Zope-dev] Searching/Indexing/ZODB/SQL/BerkleyDB > > On Thursday, November 29, 2001, at 04:03 AM, Matt Hamilton wrote: > > > On Thu, 29 Nov 2001, Chris Withers wrote: > > > >>> I would rather avoid having to use a relational database unless I > >>> have to. > >>> Perhaps the index pluggability could be made to support different > >>> backends > >>> (like FileStorage et al does). > >> > >> Yeah, unfortunately, the difficult bit is combining queries: > >> gimme the results where index1=='fish' and index2 is between 2 > >> and 5kg. > >> > >> if index1 is in SQL and index2 is in ZODB, for example, how would you > >> go about efficiently combining results? > > > > Is there not a set datatype in python that could be used? Admittedly, > > [SNIP] > > There is a 'sets' directory in the Python CVS (in the > 'nondist/sandbox' area). I think it was a proposed datatype that > didn't quite make the cut for 2.2..(?) > > Jeffrey P Shell, [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 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] Searching/Indexing/ZODB/SQL/BerkleyDB
On Thursday, November 29, 2001, at 04:03 AM, Matt Hamilton wrote: > On Thu, 29 Nov 2001, Chris Withers wrote: > >>> I would rather avoid having to use a relational database unless I >>> have to. >>> Perhaps the index pluggability could be made to support different >>> backends >>> (like FileStorage et al does). >> >> Yeah, unfortunately, the difficult bit is combining queries: >> gimme the results where index1=='fish' and index2 is between 2 >> and 5kg. >> >> if index1 is in SQL and index2 is in ZODB, for example, how would you >> go about efficiently combining results? > > Is there not a set datatype in python that could be used? Admittedly, [SNIP] There is a 'sets' directory in the Python CVS (in the 'nondist/sandbox' area). I think it was a proposed datatype that didn't quite make the cut for 2.2..(?) Jeffrey P Shell, [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] Fw: [Exuserfolder-devel] Zope 2.5b1 release
> I see an intention not to break other user folder products. Given that
> the fishbowl proposal in question is supposed to make for a very small
> change, any breakage in existing products is a bug in its implementation.
I've just checked in changes that I believe address all of the
issues (there were several):
- Part of the problem is that I picked really poor names for the
added APIs (names that had a high likelyhood of, and in fact
were used already by custom user folder implementations).
I've changed them to 'userFolderAddUser', 'userFolderEditUser'
and 'userFolderDelUsers', making the names somewhat uglier and
less likely to clash.
- They really only need to act as permission-protected aliases to
the methods that custom user folders already implement ('_doAddUser',
'_doChangeUser', '_doDelUsers'). I've done that, and custom user
folder authors don't need to take any action (other than have
implemented the '_' methods in the first place).
- Password encryption was being done in the wrong place. It really
wants to be done in the _doAddUser and _doChangeUser, so that
custom user folders can elect to do it or not (since some pw
schemes cannot work with a pre-encrypted password).
I've changed it so that the built-in Zope user folder will do
encryption, and custom user folders can support it easily by
changing their _doAddUser and _doChangeUser to do it if appropriate.
- Updated all of the comments to (hopefully) remove confusion about
'deprecation'.
So the current status is that:
- Current user folders should continue to work without any changes,
and they don't need to do anything to support the new userFolder*
convenience APIs.
- Nothing is really "deprecated" - I've changed the wording
to say that scripts and other web-based code are encouraged to
use the new userFolder* APIs to work with users rather than
create more code dependent on the crummy 'manage_users' hackery.
I've tested this on a few variations here, but I'd be happy if some
other folks who have alternate user folders around could give the
updated lib/python/AccessControl/User.py a whirl and let me know
about any problems.
Brian Lloyd[EMAIL PROTECTED]
Software Engineer 540.361.1716
Zope Corporation http://www.zope.com
___
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] ZODBC bug
Thanks Mike, I've checked this in to our CVS sources. mike hong wrote: > I found ZODBC bug at max_rows. > > file name: db.py > > line: 230 > > Current version is getting all rows regardless of max_rows. > > Fixed version is getting rows until rows are smaller than max_rows. > > Current version: > > while status==SQL_SUCCESS: > > . > > r.append(rd) > > status=SQLFetch(stmt) > > . > > Fixed version: > > cnt = 0 > > while status==SQL_SUCCESS and cnt < max_rows: > > ... > > r.append(rd) > > cnt = cnt + 1 > > status=SQLFetch(stmt) > > ... > > Have a nice day !! > ___ 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] User folders, access rights, security, collector item 47
Sorry to post here. I posted last week on the zope list about what appears to be a new/strange security related problem in 2.4.3 I thought it was a problem in LdapUserFolder, but jens spent more time debugging than I did and he feels it's somewhere in the Zope security machinery. http://collector.zope.org/Zope/47 Is it security related when security doesn't do what you want (though nothing has been exposed, rather, what we want exposed isn't)? I'd try to tackle this myself, but I really have no idea where to start. I know everyone is busy, but I was wondering if anyone else has been able to reproduce the condition so that we can say for certain if its a bug, or a mis-configuration. Thanks, Brad Clements,[EMAIL PROTECTED] (315)268-1000 http://www.murkworks.com (315)268-9812 Fax netmeeting: ils://ils.murkworks.com AOL-IM: BKClements ___ 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] Fw: [Exuserfolder-devel] Zope 2.5b1 release
> > a) The change to manage_* seems to be completely arbitrary, > since we already > >had _do* methods that meant you didn't have to call manage_users with > >fake submit buttons. So what is the point of having manage_ ? > > > They were added in response to this fishbowl proposal: > > http://dev.zope.org/Wikis/DevSite/Proposals/UserFolderXmlRpcQuickFix > > It was a quick fix intended to help people doing user management over > XML-RPC. Right - the idea was to _add to_ the existing API, in a completely backward-compatible way, so that: - "untrusted code" (DTML, Python scripts, other code managed by security constraints) could be used to do user mgmt (if the caller has appropriate rights, of course). Previously, the only code accessible to these was unwieldy (the build-a-fake- request approach), and the corresponding "_" methods were not accessible because "_" methods can't be called from Web code. - "trusted code" (external methods, Python products) would have a clearer and easier API for doing the same. While they could have used the "_" methods, they are not documented as if they are a part of the official API, which is a point of confusion. - An XML-RPC (given appropriate rights) call could be used to do user management work. > If there are problems in maintaining compatibility with the previous > API, and products that rely on that, well that's a bug and it needs > Collecting and sorting out before 2.5 final. > > I'm concerned about this too, and I'm glad it's reached Zope-Dev, as > I've got some LoginManager user folders in use, and I don't want these > to break when I start using Zope 2.5 on those systems. Nor do I - my goal for this was (and remains) 100% backward compatibility, and to make people's lives easier, not harder. It looks like I've muffed the implementation, for which I certainly take full responsibility (and which I'll rectify today). I think I also failed to adequately express the goal for this - I'll need to update the docstrings as well. The goal was not to change the (admitted ancient and crummy) way that the Web interfaces to user folders interact with the API (the dispatching based on submit button lameness), as I'm sure that many, many implementations would break. The goal was not to deprecate _that_ usage of the 'manage_users' method. The idea was to deprecate the use of 'manage_users' from Web-based or product code in favor of the new (and hopefully easier) APIs. That allows us to address the lameness of the 'manage_users' method re: user folder UI as a separate issue in the future, while still being able to give "scripters", product authors and XML-RPC users something that they can use now. Brian Lloyd[EMAIL PROTECTED] Software Engineer 540.361.1716 Zope Corporation http://www.zope.com ___ 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] Searching/Indexing/ZODB/SQL/BerkleyDB
Jim Fulton wrote: > > Chris Withers wrote: > > > > Toby Dickenson wrote: > > > > > > FileStorage is 'damn fast', so almost anything is going to be slower. > > > > Indeed, until it runs out of RAM for its indexes ;-) > > I wish you would finish testing the change I made for you. Sorry, to be clear, my comment was in the context of using a FileStorage to exclusively store searching and indexing information. Jim has provided a patch which I was trying to test, sadly, for whatever reason, it went wrong and killed the box I was testing on. There are some issues preventing me resurrecting the box (location, staff, etc) but I will let you guys know as soon as I get some information... cheers, Chris ___ 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] Fw: [Exuserfolder-devel] Zope 2.5b1 release
Steve Alexander wrote: > > In summary: > > I want to make sure that things are no worse in Zope 2.5 final than in > Zope 2.5. Any breakage caused by this API change is a bug, and needs to > be sorted out by Zope 2.5 final. That should have read: I want to make sure that the user management API is no worse in Zope 2.5 than in Zope 2.4. -- Steve Alexander ___ 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] Fw: [Exuserfolder-devel] Zope 2.5b1 release
A K Milton wrote: > > > a) The change to manage_* seems to be completely arbitrary, since we already >had _do* methods that meant you didn't have to call manage_users with >fake submit buttons. So what is the point of having manage_ ? They were added in response to this fishbowl proposal: http://dev.zope.org/Wikis/DevSite/Proposals/UserFolderXmlRpcQuickFix It was a quick fix intended to help people doing user management over XML-RPC. If there are problems in maintaining compatibility with the previous API, and products that rely on that, well that's a bug and it needs Collecting and sorting out before 2.5 final. I'm concerned about this too, and I'm glad it's reached Zope-Dev, as I've got some LoginManager user folders in use, and I don't want these to break when I start using Zope 2.5 on those systems. In the fishbowl proposal comments, Brial Lloyd wrote: This is so long overdue that I've just checked this in for the Zope 2.5 line in CVS. (It is slated for 2.5 because it is an API change and has documentation impact, plus I would like to follow up and clean up some of the old form dispatch code and want to make sure we have an upgrade cycle to make sure other implementations of user folders don't break). I see an intention not to break other user folder products. Given that the fishbowl proposal in question is supposed to make for a very small change, any breakage in existing products is a bug in its implementation. In summary: I want to make sure that things are no worse in Zope 2.5 final than in Zope 2.5. Any breakage caused by this API change is a bug, and needs to be sorted out by Zope 2.5 final. I can offer some help in fixing these bugs, especially if they find their way into the Collector, so I can take ownership of them. Improvements to the user folder API that fall outside "getting it working with XML-RPC" bring up larger issues, which I see are being discussed here: http://dev.zope.org/Wikis/DevSite/Proposals/BetterUserManagement -- Steve Alexander Software Engineer Cat-Box limited ___ 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] ZODBC bug
I found ZODBC bug at max_rows. file name: db.py line: 230 Current version is getting all rows regardless of max_rows. Fixed version is getting rows until rows are smaller than max_rows. Current version: while status==SQL_SUCCESS: . r.append(rd) status=SQLFetch(stmt) . Fixed version: cnt = 0 while status==SQL_SUCCESS and cnt < max_rows: ... r.append(rd) cnt = cnt + 1 status=SQLFetch(stmt) ... Have a nice day !!
Re: [Zope-dev] Searching/Indexing/ZODB/SQL/BerkleyDB
Chris Withers wrote: > > Toby Dickenson wrote: > > > > FileStorage is 'damn fast', so almost anything is going to be slower. > > Indeed, until it runs out of RAM for its indexes ;-) I wish you would finish testing the change I made for you. It should reduce the memory consumption by an order of magnitude. I took an afternoon out of a rather busy schedule to put this together for you. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (888) 344-4332http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ 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] Fw: [Exuserfolder-devel] Zope 2.5b1 release
Yikes, it was pointed out to me that I typed "amk" instead of "akm". Though I knew it was Andrew Milton and not Andrew Kuchling, I mixed up the letters. (In fact, as I was typing it, I was thinking "wow, that looks like Andrew Kuchling's monogram.") --Paul Paul Everitt wrote: > > Whew, that email (and the preceding one in the thread) is quite a > whopper. In substance, amk raises some pretty serious issues that we > need to come to grips with very quickly. > > I don't have enough information to respond right now, but trust that > we'll get a good response back today. > > Neo-moderator note: if the discussion _does_ start over here, everyone > is advised to leave the anger at the door. Problems like this can > usually be solved pretty easily by direct communication and open minds. > > --Paul > > Dario Lopez-Kästen wrote: > >> I thought this might be intresting for discussion on zope-dev as well... >> >> /dario >> >> - Original Message - >> From: "Andrew Kenneth Milton" <[EMAIL PROTECTED]> >> To: "Andrew Kenneth Milton" <[EMAIL PROTECTED]> >> Cc: <[EMAIL PROTECTED]> >> Sent: Thursday, November 29, 2001 8:45 AM >> Subject: Re: [Exuserfolder-devel] Zope 2.5b1 release >> >> It has been pointed out that perhaps the dripping sarcasm drowned out the >> acutal points of the email, sorry I was particularly pissed off at how >> half-assed it all was. >> >> If you are writing a product that needs to create a user, you go look in >> User.py and find out what the API since that tends to be the only place >> the API is documented. >> >> If you look at how UserFolder is implemented; >> >> a) The change to manage_* seems to be completely arbitrary, since we >> already >>had _do* methods that meant you didn't have to call manage_users with >>fake submit buttons. So what is the point of having manage_ ? >> >> b) manage_* methods usually indicate web callable methods, which these >> clearly >>aren't (no docstring, no REQUEST parameter). In fact they don't >> return a >> status >>at all, so they seem to doubly useless. >> >> c) If it's an internal API for applications then the methods should >> probably >>be protected by being prefixed with an _ to indicate they're not for >> calling >>from the web or from within Documents/Templates. >> >> d) Even if you conformed to the API by calling e.g. manage_addUser() this >>seemed to be incorrect, since it didn't do things like encrypt the >> password. >>This meant you would have to either a) encrypt the password yourself >>(*very bad for XUF*), or b) call _addUser() which is not part of a >> defined >>API but looks like it should be (i.e. manage_addUser and _addUser >> seem to >>be reversed in functionality). >> >>ii) This is compounded by the fact you would have to query the >> UserFolder >>itself to find out if you should be encrypting passwords (what no >>UserFolder capability API?). >> >> e) s/_do/manage_/ doesn't constitute a new API. It's just the old one >> with >> the >>names changed. >> >> f) We've done a lot of work to make a flexible UF product that is I18Ned >>(well -able), and they still use the value of the submit button. I >> would >> have >>expected to see an alternative manage_users called from the ZMI that >>behaved much better, with manage_users calls raising warnings. >> >> g) Someone got paid to do it, and that just pisses me off, given the >> quality >>of the stuff we release for free (and I'm still looking for a job btw >> d8). >>We're not perfect, the 0.10.1 release shows that, but, at least we >>spent more than three minutes including thinking time on it, and I at >> least >>try not to change things just for the sake of it. >> >> Anyway. In case you were wondering what the previous email meant, there's >> the >> actual meaning d8) >> >> -- >> Totally Holistic Enterprises Internet| | Andrew >> Milton >> The Internet (Aust) Pty Ltd | | >> ACN: 082 081 472 ABN: 83 082 081 472 | M:+61 416 022 411 | Carpe >> Daemon >> PO Box 837 Indooroopilly QLD 4068|[EMAIL PROTECTED]| >> >> ___ >> Exuserfolder-devel mailing list >> [EMAIL PROTECTED] >> https://lists.sourceforge.net/lists/listinfo/exuserfolder-devel >> >> >> >> ___ >> 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 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] Searching/Indexing/ZODB/SQL/BerkleyDB
On Thu, 29 Nov 2001, Chris Withers wrote: > > I would rather avoid having to use a relational database unless I have to. > > Perhaps the index pluggability could be made to support different backends > > (like FileStorage et al does). > > Yeah, unfortunately, the difficult bit is combining queries: > gimme the results where index1=='fish' and index2 is between 2 and 5kg. > > if index1 is in SQL and index2 is in ZODB, for example, how would you > go about efficiently combining results? Is there not a set datatype in python that could be used? Admittedly, most of the stuff in MG is about textual searches rather than exact searches (it can do boolean searches too, but the book is mainly about ranking). It uses an algorithm called the 'Cosine Ranking Algorithm'. Basically if you imagine an N-dimensional space, where N is the number of terms in your vocabulary and represent a document as a vector in that space whose direction is the composite of the terms that appear in it. You then represent a query string as a vector in the same space, the similarity between the document and the query is the angle between the two vectors... the smaller the angle the greater the similarity. Still with me? :) -Matt -- Matt Hamilton [EMAIL PROTECTED] Netsight Internet Solutions, Ltd. Business Vision on the Internet http://www.netsight.co.uk +44 (0)117 9090901 Web Hosting | Web Design | Domain Names | Co-location | DB Integration ___ 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] Fw: [Exuserfolder-devel] Zope 2.5b1 release
Whew, that email (and the preceding one in the thread) is quite a whopper. In substance, amk raises some pretty serious issues that we need to come to grips with very quickly. I don't have enough information to respond right now, but trust that we'll get a good response back today. Neo-moderator note: if the discussion _does_ start over here, everyone is advised to leave the anger at the door. Problems like this can usually be solved pretty easily by direct communication and open minds. --Paul Dario Lopez-Kästen wrote: > I thought this might be intresting for discussion on zope-dev as well... > > /dario > > - Original Message - > From: "Andrew Kenneth Milton" <[EMAIL PROTECTED]> > To: "Andrew Kenneth Milton" <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Thursday, November 29, 2001 8:45 AM > Subject: Re: [Exuserfolder-devel] Zope 2.5b1 release > > It has been pointed out that perhaps the dripping sarcasm drowned out the > acutal points of the email, sorry I was particularly pissed off at how > half-assed it all was. > > If you are writing a product that needs to create a user, you go look in > User.py and find out what the API since that tends to be the only place > the API is documented. > > If you look at how UserFolder is implemented; > > a) The change to manage_* seems to be completely arbitrary, since we already >had _do* methods that meant you didn't have to call manage_users with >fake submit buttons. So what is the point of having manage_ ? > > b) manage_* methods usually indicate web callable methods, which these > clearly >aren't (no docstring, no REQUEST parameter). In fact they don't return a > status >at all, so they seem to doubly useless. > > c) If it's an internal API for applications then the methods should probably >be protected by being prefixed with an _ to indicate they're not for > calling >from the web or from within Documents/Templates. > > d) Even if you conformed to the API by calling e.g. manage_addUser() this >seemed to be incorrect, since it didn't do things like encrypt the > password. >This meant you would have to either a) encrypt the password yourself >(*very bad for XUF*), or b) call _addUser() which is not part of a > defined >API but looks like it should be (i.e. manage_addUser and _addUser seem to >be reversed in functionality). > >ii) This is compounded by the fact you would have to query the UserFolder >itself to find out if you should be encrypting passwords (what no >UserFolder capability API?). > > e) s/_do/manage_/ doesn't constitute a new API. It's just the old one with > the >names changed. > > f) We've done a lot of work to make a flexible UF product that is I18Ned >(well -able), and they still use the value of the submit button. I would > have >expected to see an alternative manage_users called from the ZMI that >behaved much better, with manage_users calls raising warnings. > > g) Someone got paid to do it, and that just pisses me off, given the quality >of the stuff we release for free (and I'm still looking for a job btw > d8). >We're not perfect, the 0.10.1 release shows that, but, at least we >spent more than three minutes including thinking time on it, and I at > least >try not to change things just for the sake of it. > > Anyway. In case you were wondering what the previous email meant, there's > the > actual meaning d8) > > -- > Totally Holistic Enterprises Internet| | Andrew Milton > The Internet (Aust) Pty Ltd | | > ACN: 082 081 472 ABN: 83 082 081 472 | M:+61 416 022 411 | Carpe Daemon > PO Box 837 Indooroopilly QLD 4068|[EMAIL PROTECTED]| > > ___ > Exuserfolder-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/exuserfolder-devel > > > > ___ > 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 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] Fw: [Exuserfolder-devel] Zope 2.5b1 release
Dario Lopez-Kästen wrote: > > Anyway. In case you were wondering what the previous email meant, there's > the > actual meaning d8) I'm sure Andy's got a point, but we haven't got the context of those points. Is he complaining about the change in UserFolder API in Zope 2.5? cheers, Chris ___ 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] Searching/Indexing/ZODB/SQL/BerkleyDB
Casey Duncan wrote: > > I'm not sure I want to store the indexes in the ZODB, just index ZODB data at > a low level. Ah, okay, and yes, in that case, I am in complete agreement ;-) (the level I'm aiming at is just to be able to index python objects, I'll leave plugging that into the ZODB architecture up to someone who understands it better...) > Yup, I think I have a solution, but it'll involve some coding ;^) Ooo...care to explain? :-) > I would rather avoid having to use a relational database unless I have to. > Perhaps the index pluggability could be made to support different backends > (like FileStorage et al does). Yeah, unfortunately, the difficult bit is combining queries: gimme the results where index1=='fish' and index2 is between 2 and 5kg. if index1 is in SQL and index2 is in ZODB, for example, how would you go about efficiently combining results? > > That said, I wasn't aware of Matt's work up until very recently. I'd love > > to see an Indexer that didn't require an RDB (or BerkleyDB :-P) and scaled > > to GigaBytes of Data... > > Yup, me too. Well, I'm just purchasing my copy of Managing Gigabytess now ;-) > OK, I'm available all this week, but I'm not as available the next two weeks. > Lets find a good time. I'm available any time and date, just as long as I get a coupla days notice... cheers, Chris ___ 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] Searching/Indexing/ZODB/SQL/BerkleyDB
Andreas Jung wrote: > > Storage of indexed data is one aspect but there is also need for components > like > lexers, stemmers, splitters etc. Oracle Intermedia as an example has a very > flexible > architecture to handle these components (for all that Oracle Intermedia > sucks). Hmmm... hopefully that isn't _why_ it sucks ;-) > It would be also interesting to catalog structured documents (e.g. XML) to > be able to > specifies queries that involve structural informations. Yup, although right now I'm specifically interested in giving python and zope an easy to use indexing engine that does full text properly and scales well. The other problems appear to be somewhat easier to solve... > Such a project is not trivial and can not be handled by one person but > requires several > volunteers ;-) If you're making an assumption about the way I'm working there, you may be mistaken ;-) Chris ___ 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] Catalog improvements
Andreas Jung wrote: > > I think the software "MG" from the book "Managing Gigabytes" is GPLed and > currently > released as mg-1.21. Walking through the TOC of the book, it seems to be a > very detailed > sources about text processing and gives very much informations about > different indexes types. > But I miss some explanations about current data structures like suffix > arrays or suffix tree > that have several advantages for text processing compared to B-Trees. Hmmm... looks like it's time ot go buy a book :-) cheers, Chris ___ 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] Searching/Indexing/ZODB/SQL/BerkleyDB
"Barry A. Warsaw" wrote: > > than the factor of 100 your numbers showed for you data! I would not > make the blanket assertion that Berkeley storage is 100 times slower > than FileStorage. Sorry, let me clarify as well, I only meant in the context of searching and indexing... > Let me just reiterate: it's vitally important to tune your Berkeley > storage for your system and application, especially with regards to > cachesize. E.g. Getting the cachesize wrong can definitely destroy > your performance, maybe producing numbers as bad as you're seeing. > I won't claim that Berkeley DB is easy to tune, though. Indeed... and I've spent a while twiddling cache sizes to no avail ;-) cheers, Chris ___ 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] Fw: [Exuserfolder-devel] Zope 2.5b1 release
I thought this might be intresting for discussion on zope-dev as well... /dario - Original Message - From: "Andrew Kenneth Milton" <[EMAIL PROTECTED]> To: "Andrew Kenneth Milton" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Thursday, November 29, 2001 8:45 AM Subject: Re: [Exuserfolder-devel] Zope 2.5b1 release It has been pointed out that perhaps the dripping sarcasm drowned out the acutal points of the email, sorry I was particularly pissed off at how half-assed it all was. If you are writing a product that needs to create a user, you go look in User.py and find out what the API since that tends to be the only place the API is documented. If you look at how UserFolder is implemented; a) The change to manage_* seems to be completely arbitrary, since we already had _do* methods that meant you didn't have to call manage_users with fake submit buttons. So what is the point of having manage_ ? b) manage_* methods usually indicate web callable methods, which these clearly aren't (no docstring, no REQUEST parameter). In fact they don't return a status at all, so they seem to doubly useless. c) If it's an internal API for applications then the methods should probably be protected by being prefixed with an _ to indicate they're not for calling from the web or from within Documents/Templates. d) Even if you conformed to the API by calling e.g. manage_addUser() this seemed to be incorrect, since it didn't do things like encrypt the password. This meant you would have to either a) encrypt the password yourself (*very bad for XUF*), or b) call _addUser() which is not part of a defined API but looks like it should be (i.e. manage_addUser and _addUser seem to be reversed in functionality). ii) This is compounded by the fact you would have to query the UserFolder itself to find out if you should be encrypting passwords (what no UserFolder capability API?). e) s/_do/manage_/ doesn't constitute a new API. It's just the old one with the names changed. f) We've done a lot of work to make a flexible UF product that is I18Ned (well -able), and they still use the value of the submit button. I would have expected to see an alternative manage_users called from the ZMI that behaved much better, with manage_users calls raising warnings. g) Someone got paid to do it, and that just pisses me off, given the quality of the stuff we release for free (and I'm still looking for a job btw d8). We're not perfect, the 0.10.1 release shows that, but, at least we spent more than three minutes including thinking time on it, and I at least try not to change things just for the sake of it. Anyway. In case you were wondering what the previous email meant, there's the actual meaning d8) -- Totally Holistic Enterprises Internet| | Andrew Milton The Internet (Aust) Pty Ltd | | ACN: 082 081 472 ABN: 83 082 081 472 | M:+61 416 022 411 | Carpe Daemon PO Box 837 Indooroopilly QLD 4068|[EMAIL PROTECTED]| ___ Exuserfolder-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/exuserfolder-devel ___ 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 )
