April 2002 - Zope-Dev

Re: [Zope-dev] how bad are per-request-write-transactions (fwd)
by Romain Slootmaekers 17 Apr '02

17 Apr '02

On Wed, 17 Apr 2002, Paul Everitt wrote: > > I don't agree that high write is always forbidden. I think there are > plenty of cases where this can work. It simply becomes unworkable much > sooner than other data systems (e.g. a relational database or FS-based > solution). > > For instance, think about bloat for a second. Let's be crazy and say it > takes 100 bytes to store an integer representing a count. Let's say you > write once a second. That's under 7Mb a day (per counter). Combined > with hourly packing, that might be well within limits. > > Let's take the next step and say that you can live with a little > volatility in the data. You write an object that caches ten seconds > worth of writes. Whenever a write comes in at the over-ten-second mark, > you write the _v_ attribute to the persistent attribute. There's an > order of magnitude improvement. > > Finally, you store all your counters in a non-versioned storage. Now > you have *no* bloat problem. :^) > > Regarding performance, maybe his application isn't doing 50 > requests/second and he'd be willing to trade the slight performance hit > and bloat for a decrease in system complexity. > > All of the above has downsides as well. My point, though, is that we > shouldn't automatically dismiss the zodb as inappropriate for *all* > high-write situations. In fact, with Andreas and Matt Hamilton's > TextIndexNG, you might even be able to write to catalogued applications > at a faster rate than one document per minute. :^) > for one web application, we use the ZODB as primary storage mechanism, and apart from the need for frequent packing, we are quite happy. we did however have to modify the conflict resolution protocol for our objects. We now have the luxury of not having to store your objects in base64 encoded sql blobs ;) As far as performance is goes... performance is never an issue until it becomes one. 99% of the time, I don't care. the 1 other % was solved within a day. Sloot.

1 0

death to index_html; ObjectManager?
by Toby Dickenson 17 Apr '02

17 Apr '02

I am seeing some undesirable effects of the recent 'death to index_html' changes. Folders now have a 'Settings' tab to allow managers to change the default document. This is good. However, the implementation of this lies in the ObjectManager class. The browser-default capabilities may not make sense for other classes, derived from ObjectManager, which are not general purpose 'folders'. I think it would make more sense for the browser-default implementation to sit in a new mixin base class, perhaps OFS.BrowserDefaultManager.BrowserDefaultManager, to be included as a base class of OFS.Folder.Folder but not OFS.ObjectManager.ObjectManager. Any thoughts? Toby Dickenson tdickenson(a)geminidataloggers.com

5 8

Is there a de facto standard for manage_add() behavior?
by Craeg K Strong 16 Apr '02

16 Apr '02

Hello: I have a question about style. My ExternalFile product enables one to create zope objects that behave like DTML methods or DTML documents but point to external files for their content. The creation routines handle many different possible cases - external file does not exist yet, create it blank - external file exists - external file does not exist yet, upload a file and create it with uploaded content etc, etc. My manage_add() routine handles all of these cases, posting up confirmation dialogs, etc. when necessary. It then calls either create_file() and/or create_object() to actually _create_ the external file (if necessary) and the ExternalFile instance (always). The problem is this: many users create ExternalFile instances programmatically. To do this, they expect to call manage_add() when instead (according to my design) they should be calling create_object() directly. The question is-- am I violating some kind of de facto Zope standard? Is manage_add() supposed to silently create an object without any sort of confirmation dialogs? Or is this a simple case of insufficient documentation-- I should make it more clear in the docs which methods to call in order to create programmatically? Of course, with Zope3 this wouldn't be an issue, because you have pluggable GUIs. Don't like the default dialogs? Plug in your own with by changing the deployment descriptor... In the meantime, however-- for Zope 2x, what do the Zope style mavens suggest? Regards, --Craeg

1 0

[RFClet]: What about the request method and the client side trojan?
by Oliver Bleutgen 16 Apr '02

16 Apr '02

The issue of client side trojan recently came to my mind again. Looking at http://www.zope.org//Members/jim/ZopeSecurity/ClientSideTrojan I found nothing new since Oct. 2001, so I thought I bring up the issue again, maybe it's something which could be taken care of for zope => 2.6. I wrote something about that at the wiki, but let me repeat my proposal. I think zope's management methods (the potentially destructive ones) should not accept REQUESTs with REQUEST_METHOD "GET". This is in accordance with the http/1.1 rfc (reposted from the wiki): "Implementors should be aware that the software represents the user in their interactions over the Internet, and should be careful to allow the user to be aware of any actions they might take which may have an unexpected significance to themselves or others. In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested." The win would be that disabling javascipt would make a client save from this form of attack, AFAIK, OTOH I can't think of anything which would break ATM. cheers, oliver

8 25

Separate staging and development areas for a product
by Ted Skolnick 16 Apr '02

16 Apr '02

Hi, I have a Zope product in development. I want to setup a staging area for stable releases and I am not sure how to go about it. I could install another Zope in a different directory, but it seems like I should be able to do it with the Zope instance I've got. Any thoughts, or pointers? My project contains ZSQL methods and external methods, if that is significant. It seems like the external methods could be a rub, since they exist as files in the Zope installation directories (specifically in the Extensions directory). I don't know how I could have multiple versions of these files, one for development, one for staging all within one instance of Zope. One lesser question, newbie question... how do I control the URL to reach the methods exposed in my project. For example, I have a product called myproj, with my method. The only URL I can get to work is this.... http://myserver/Control_Panel/Products/myproj/mymethod I'd like to have a URL that looks like this... http://myserver/myproj/mymethod without the Control_Panel bit. thanks, Ted

2 1

ZEO 1.0 final release
by Jeremy Hylton 15 Apr '02

15 Apr '02

I am happy to announce that ZEO 1.0 final was released today. Zope Enterprise Objects (ZEO) provides the ability for multiple processes to use a single Zope Object Database. ZEO turns the Zope object system in a distributed architecture, allowing multiple processors, machines, and networks to act as one website. For more information and downloads, see the ZEO web page at http://www.zope.org/Products/ZEO. ZEO 1.0 will work with Zope 2.2 or higher and with StandaloneZODB 1.0. The 1.0 release comes after one year of beta testing, which results in several important bug fixes and increased stability. ZEO 1.0 has been used in production environment supporting hundreds of requests per second. See CHANGES.txt for details about bugs fixed. Jeremy

1 0

External methods in Extensions folder under Product
by Ted Skolnick 15 Apr '02

15 Apr '02

Hi, I currently have my external methods under the Extensions folder within the Zope installation (i.e. /usr/local/Zope/Extensions ). I read that I could place them in Extensions folders within specific installed products. I'd much prefer that, but can't seem to get it working. What I did: I have a product I created through the management interface called "myproduct". I created a directory on the files system like this... /usr/local/Zope/lib/python/Products/myproduct/Extensions Inside there I put my test.py module, and try to add it as an external method to that product. I get a message that test.py can't be found. If I put it in the general Extensions folder for the Zope install, all is well. Any ideas? thanks, Ted

2 1

__after_publishing_traverse__
by Ivo van der Wijk 15 Apr '02

15 Apr '02

Hi All, I would like to do some bookkeeping *after* an object has been published, i.e. imagine a request is done for: /a/b/c/d 'b' is the (folderish) object that does the accounting, 'd' is the object to be published. I would like 'b' to examine the RESPONSE after publishing. I know there's a __before_publishing_traverse__, however, this is not what I want. Does someone know a way to implement this cleanly? I.e. without monkeypatching 'd' (which can be any kind of zope object)? Regards, Ivo -- Drs. I.R. van der Wijk -=- Brouwersgracht 132 Amaze Internet Services V.O.F. 1013 HA Amsterdam, NL -=- Tel: +31-20-4688336 Linux/Web/Zope/SQL/MMBase Fax: +31-20-4688337 Network Solutions Web: http://www.amaze.nl/ Consultancy Email: ivo(a)amaze.nl -=-

5 6

Overriding HTTPResponse.unauthorized()
by Matt Behrens 15 Apr '02

15 Apr '02

I've got some rather funky auth requirements where I need to stop Zope from challenging Basic authentication when Unauthorized is raised. I seem to be able to do this if I monkey-patch HTTPResponse.unauthorized(), but what I'd really like is to be able to hook into it to make a user folder-overridable challenge with a fallback to the standard unauthorized. Maybe such a hook would be useful in 2.6 :-) So, given that, can I get to the user folder from HTTPResponse.unauthorized()? Or are there any better ideas?

2 1

ZEO Server Crashed
by Alex Kelly 15 Apr '02

15 Apr '02

We have been running our web site with Zope 2.4.2 and ZEO (I'm unsure of the version, can't seem to find it anywhere) for about 5 months. We are running it on Solaris 8 w/ Python 2.1.2. The other day we had a major crash and this was left in the ZEO_Server.log: 2002-04-09T16:36:49 ERROR(200) ZEO Server uncaptured python exception, closing channel <StorageServer listening :5800 at 47a074> (exceptions.OSError:[Errno 24]Too many open files [/opt/Lang/Python-2.1.2/lib/python2.1/asyncore.py|poll|92] [/opt/Lang/Python-2.1.2/lib/python2.1/asyncore.py|handle_read_event|380] [/opt/WWW/ZopeInstallation/Zope_software_home/lib/python/ZEO/StorageServer.py|handle_accept|189] [/opt/WWW/ZopeInstallation/Zope_software_home/lib/python/ZEO/StorageServer.py|__init__|238] [/opt/WWW/ZopeInstallation/Zope_software_home/lib/python/ZEO/trigger.py|__init__|133]) Any clues as to what caused this? Or any information about making sure this doesn't happen again? Thanks Alex Kelly Internet System Administrator Franklin University

2 1