Re: [Zope-dev] Last-modified and bobobase_modification_time
Wei He wrote: On Mon, 17 Jun 2002, Dieter Maurer wrote: R. David Murray writes: ... Well, there's two aspects to this. The first one is the quesiton of *why* the last modified header is currently that of the outermost page template. That's a [EMAIL PROTECTED] question. The second is the question of whether or not that is the right behavior, and what it would take to make Zope smarter such that the last modified header would actually be accurate. Think about it. It is very difficult. In order to determine the accurate modification time, you need to render the template (as it is non-trivial to determine the set of objects the rendering depends on without actually doing the rendering). Rendering may produce side effects. But HEAD requests are required by HTTP not to have side effects. Thus, you cannot have accurate modified headers for HEAD requests. Moreover, usually HEAD requests do not pass the necessary parameters for template rendering. Would please go a little bit deeper giving an example what information HEAD requests don't pass to the server, although it's beyond this topic. HEAD requests are required to have no side effects. On the other hand they are required to return the same response as GET requests without the BODY. So GET returning another last-modified header than HEAD would be in violation of the RFC. This gets worse by the fact that HEAD can be used for caching purposes. cheers, oliver ___ 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] Last-modified and bobobase_modification_time
Wei He wrote: On Tue, 18 Jun 2002, Oliver Bleutgen wrote: Would please go a little bit deeper giving an example what information HEAD requests don't pass to the server, although it's beyond this topic. HEAD requests are required to have no side effects. On the other hand they are required to return the same response as GET requests without the BODY. So GET returning another last-modified header than HEAD would be in violation of the RFC. This gets worse by the fact that HEAD can be used for caching purposes. Totally understood. But the question is what RFC says about the last-modified header. Shouldn't it reflect the latest update? Zope is facing this problem because it handles the HEAD request seperately. Am I right? I don't see any need to seperately handle the HEAD request. My hacking of the last-modified header is done execpt that HEAD and wget -S returns different headers. I think the last step is to change the HEAD handling routine to the get information from GET. Does anyone have any idea? If you *really* want to, you can run a HEAD just like a GET, but after getting your last-modified and other details, abort the transaction to undo side-effects, then return the HEAD response. I would generally recommend against this, as it may end up being rather expensive. -- 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] Crash Burn with Zope 2.6.0a1 and ZEO 2.0a1
I have failed as well to upgrade a Zope 2.5.1/ZEO 1.0 installation to
2.6.0a1. I tried to start *the very same instance* that runs successfully
under 2.5.1 with 2.6.0a1. This is what I found out:
* The Catalog problem you see comes from
Products.PluginIndexes.TextIndex.Splitter.ZopeSplitter not exporting
'Splitter' anymore. I should really have been kept for bw compatibility.
Workaround is to copy ZopeSplitter's __init__.py from 2.5.1.
* ZEO 1.0 ClientStorage does not work and I have no clue why it would not
find trigger.py anymore. Do I *need* ZEO 2.0a1 for 2.6.0a1? There is
nothing in the release notes.
Traceback (most recent call last):
File /Zope-2.6.0a1/z2.py, line 832, in ?
asyncore.loop()
File /Zope-2.6.0a1/lib/python/ThreadedAsync/LoopCallback.py, line 100,
in loop
_start_loop(map)
File /Zope-2.6.0a1/lib/python/ThreadedAsync/LoopCallback.py, line 70,
in _start_loop
apply(cb, (map,) + args, kw or {})
File /home/zeo6/lib/python/ZEO/ClientStorage.py, line 215, in
becomeAsync
File /home/zeo6/lib/python/ZEO/ClientStorage.py, line 556, in getWakeup
ImportError: No module named trigger
* Formulator
Formulator failed to install due to ZODB conflict errors until I put
get_transaction.commit() into Formulator's initialize(); twice, after the
help registrations.
* New Startup:
Will the new startup stuff also be available for ther ZEO server's
start.py? Until 2.5.1 I was able to run ZEO server client in-place (from
the same directory). This is harder with 2.6.0. I needed some file
permission trickery (which defeats many of the benefits of the new startup)
to make it work.
* Besides:
Z2.pid is created very late. I cannot ./stop a half-started Instance (not
even a ZEO client waiting for the server!). Could we create the pid file
earlier?
Rgds,
Stefan
--On Montag, 17. Juni 2002 16:23 -0500 Andrew Sydelko [EMAIL PROTECTED]
wrote:
Well, I have a 3gig ZODB that we have been using fine with
Zope 2.5.1 / ZEO 1.0.
Trying Zope 2.6.0a1 and ZEO 2.0a1. The storage server seemed to come
up fine, but when trying to start the ZEO client it pretty much sucked.
I really should include the log file it produced but it's quite long.
I put it up at http://eng.purdue.edu/people/sydelko/zope_2.6a1_log_1
It ended up dying at the end, but that I think I can fix.
I'd really like someone to clue me into why everything else complained.
--
BLOWFISH, n. - Preference for beef.
___
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] Last-modified and bobobase_modification_time
Rendering may produce side effects. But HEAD requests are required by HTTP not to have side effects. RFC 2616 section 9.4 states that HEAD is identical to GET in this respect, and both should have no side effects. On Tuesday 18 Jun 2002 10:26 am, Wei He wrote: I think the last step is to change the HEAD handling routine to the get information from GET. Does anyone have any idea? Yes, I think that makes sense. A while ago the list discussed changing Zope's security declarations to add a way to specify whether a published method has significant side-effects. Side-effect-free methods can have HEAD and GET handled identically. Methods declared to have side-effects can only be accessed though a POST. I guess GET or HEAD on such methods would result in a 405 error (Method Not Allowed) (Such a change would also go a long way to reducing the scope of client-side-trojan vulnerabilities.) ___ 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] Last-modified and bobobase_modification_time
Toby Dickenson wrote: Rendering may produce side effects. But HEAD requests are required by HTTP not to have side effects. RFC 2616 section 9.4 states that HEAD is identical to GET in this respect, and both should have no side effects. On Tuesday 18 Jun 2002 10:26 am, Wei He wrote: I think the last step is to change the HEAD handling routine to the get information from GET. Does anyone have any idea? Yes, I think that makes sense. A while ago the list discussed changing Zope's security declarations to add a way to specify whether a published method has significant side-effects. Side-effect-free methods can have HEAD and GET handled identically. Methods declared to have side-effects can only be accessed though a POST. I guess GET or HEAD on such methods would result in a 405 error (Method Not Allowed) (Such a change would also go a long way to reducing the scope of client-side-trojan vulnerabilities.) Yes, and sadly this discussion died a miserable death. This is the point I omitted in my other reply. Dieter presumtion that GET can have sideeffect in zope, while right, shows exactly the problem with not following the RFC recommendations. I know that it is nearly impossible to follow this strictly - as far as I see it wouldn't even allow showing visitor stats on a frontpage - but zope should at least offer some infrastructure to handle this. And it absolutly should be stricter in it's management interfaces and such. To be clear, the RFC says: HEAD SHOULD NOT have sideffects. GET SHOULD NOT have sideffects. HEAD SHOULD return the same http-headers as GET. So none of the discussed changes would make zope violate the RFC, as it doesn't really require the above, it just recommends. cheers, oliver ___ 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] RFC 2616, side effects, and idempotence (was:Last-Modified....)
On Tue, 18 Jun 2002, Oliver Bleutgen wrote: Toby Dickenson wrote: Rendering may produce side effects. But HEAD requests are required by HTTP not to have side effects. RFC 2616 section 9.4 states that HEAD is identical to GET in this respect, and both should have no side effects. This bugged me the first time this discussion went around, and I feel impelled to clearify it now, even though it is a little tangential to the core of the discussion. I guess I'm just a precisionist when it comes to terminology grin. The RFC does *NOT* say that GET and HEAD must have no side effects. That is just the simplist implementation of what it *dees* say, which is that GET and HEAD must be idempotent. When Tim (I think it was) mentioned this in the first round of this disucssion, I had to look it up even though it is a good math term and I was a math major. What it means is that once you do a GET or HEAD request, any *subsequent* GET or HEAD request for that same URI may not change the state of the system. But the *first* access to that URI *can* change the state of the system. (See section 9.1.2.) So it seems to me that some of the concern I have seen in Zope code with avoiding write on read, where a GET request would otherwise trigger the one-time initialization of something in the database, is misplaced if the concern that motivates it is adhering to this spec. There may well be other reasons to wish to avoid idempotent write-on-read (although I haven't thought of any yet), but RFC 2616 isn't one of them. NB: There seems to be a small bug in the spec, in that it does not say that any sequence of GET and HEAD requests on the same URI should be idempotent, but that is clearly the intent. --RDM PS: somehow, I don't think the spec writers thought much about hit counters... ___ 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] RFC 2616, side effects, and idempotence (was: Last-Modified....)
On Tuesday 18 Jun 2002 2:15 pm, R. David Murray wrote: RFC 2616 section 9.4 states that HEAD is identical to GET in this respect, and both should have no side effects. This bugged me the first time this discussion went around, and I feel impelled to clearify it now, even though it is a little tangential to the core of the discussion. I guess I'm just a precisionist when it comes to terminology grin. Yes, you are precisely correct. Thanks. So it seems to me that some of the concern I have seen in Zope code with avoiding write on read, where a GET request would otherwise trigger the one-time initialization of something in the database, is misplaced if the concern that motivates it is adhering to this spec. Yes, I dont think this is a problem. NB: There seems to be a small bug in the spec, in that it does not say that any sequence of GET and HEAD requests on the same URI should be idempotent, but that is clearly the intent. PS: somehow, I don't think the spec writers thought much about hit counters... I like the phrase 'largely idempotent' to refer to what we want from a GET or a HEAD. A page with a hit counter is 'largely idempotent'. ___ 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] RFC 2616, side effects, and idempotence (was: Last-Modified....)
R. David Murray wrote: On Tue, 18 Jun 2002, Oliver Bleutgen wrote: Toby Dickenson wrote: Rendering may produce side effects. But HEAD requests are required by HTTP not to have side effects. RFC 2616 section 9.4 states that HEAD is identical to GET in this respect, and both should have no side effects. First, your quoting is wrong, I didn't write that - talk about precisionist *g*. This bugged me the first time this discussion went around, and I feel impelled to clearify it now, even though it is a little tangential to the core of the discussion. I guess I'm just a precisionist when it comes to terminology grin. The RFC does *NOT* say that GET and HEAD must have no side effects. That is just the simplist implementation of what it *dees* say, which is that GET and HEAD must be idempotent. When Tim (I think it was) mentioned this in the first round of this disucssion, I had to look it up even though it is a good math term and I was a math major. This doesn't cover everything. First, you're right, the RFC indeed doesn't say MUST anywhere concerning the areas we are talking about. This is important. Zope does not violate the RFC. But, the RFC introduces two, let's say attributes to methods. One is idempotent, which is described in 9.1.2 which you righlty refer to. But, there's also the attribute safe, which is described in 9.1.1: 9.1.1 Safe Methods 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. Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them. Which is IMO exactly what we were talking about in that thread. So it seems to me that some of the concern I have seen in Zope code with avoiding write on read, where a GET request would otherwise trigger the one-time initialization of something in the database, is misplaced if the concern that motivates it is adhering to this spec. There may well be other reasons to wish to avoid idempotent write-on-read (although I haven't thought of any yet), but RFC 2616 isn't one of them. Perhaps it is. I don't know the areas of the code where you have seen that, but it might be inspired not by the problem of idempotence, but of safeness PS: somehow, I don't think the spec writers thought much about hit counters... Lol, I think so too. cheers, oliver ___ 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] problems with accented characters - need advice
hello, we are looking for a simple solution to ensure that objects added to the zope database have valid names... including those which start out containing accented characters ( we are in europe ). we are considering making the change in our PUT, located in NullResource.py in the webdav area. we are wondering if anyone has any comments about this solution... is it a good idea. anyone have any other ideas? we have a process method for correcting accented characters and is located in the constructor of the object class : it works like ob.id = processID(name) here is the change...we have added 'ob.id or name' to setObject method request. code starts here # Delegate actual PUT handling to the new object. ob.PUT(REQUEST, RESPONSE) self.__parent__._setObject(ob.id or name, ob) Eric Brun Savoie Technologie Savoie Technolac ___ 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] Crash Burn with Zope 2.6.0a1 and ZEO 2.0a1
AS == Andrew Sydelko [EMAIL PROTECTED] writes: AS Trying Zope 2.6.0a1 and ZEO 2.0a1. The storage server seemed to AS come up fine, but when trying to start the ZEO client it pretty AS much sucked. It looks like you would have had the same problems without ZEO. It would be helpful if you could try running Zope without ZEO, just with FileStorage. AS I really should include the log file it produced but it's quite AS long. I put it up at AS http://eng.purdue.edu/people/sydelko/zope_2.6a1_log_1 AS It ended up dying at the end, but that I think I can fix. AS I'd really like someone to clue me into why everything else AS complained. The errors in the log are all about failures to import specific modules. (Let me know if I missed something else.) Failed to import class Splitter from module Products.PluginIndexes.TextIndex.Splitter.ZopeSplitter When I import Products...ZopeSplitter, I see a module with a Splitter attribute bound to a function. The other import problem I see is Zope Could not import Products.HTMLDocument Is HTMLDocument a standard product or a 3rd party product? I don't see one in my 2.6 checkout. If it's 3rd part, then I expect it needs to be upgrade to work with 2.6. Jeremy ___ 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] Crash Burn with Zope 2.6.0a1 and ZEO 2.0a1
Stefan H. Holek wrote: Z2.pid is created very late. I cannot ./stop a half-started Instance (not even a ZEO client waiting for the server!). Could we create the pid file earlier? Actually Z2.pid *is* now created earlier than with 2.5.1, the setuid stuff for root startups was moved after the Z2.pid creation to stop a potential security issue. I don't see any reason it couldn't be created before the servers are started, however. Others may have reasons why. ___ 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] Crash Burn with Zope 2.6.0a1 and ZEO 2.0a1
On Tue, 18 Jun 2002 11:20:21 -0400 Jeremy Hylton [EMAIL PROTECTED] wrote: AS == Andrew Sydelko [EMAIL PROTECTED] writes: AS Trying Zope 2.6.0a1 and ZEO 2.0a1. The storage server seemed to AS come up fine, but when trying to start the ZEO client it pretty AS much sucked. It looks like you would have had the same problems without ZEO. It would be helpful if you could try running Zope without ZEO, just with FileStorage. Hmm... The first time I copied the 3gig Data.fs over and tried to start Zope a few times. After fiddling with the permissions of the var directory it finally started, but the Data.fs was only 2MB! So I copied it again. And once again, the 3gig Data.fs is blown away! What am I doing wrong??? What are the permissions of the var folder supposed to be? I'm starting Zope with: python Zope/z2.py -w 8080 -F 8081 -W 8082 -u httpd AS I really should include the log file it produced but it's quite AS long. I put it up at AS http://eng.purdue.edu/people/sydelko/zope_2.6a1_log_1 AS It ended up dying at the end, but that I think I can fix. AS I'd really like someone to clue me into why everything else AS complained. The errors in the log are all about failures to import specific modules. (Let me know if I missed something else.) Failed to import class Splitter from module Products.PluginIndexes.TextIndex.Splitter.ZopeSplitter When I import Products...ZopeSplitter, I see a module with a Splitter attribute bound to a function. I don't understand what you're saying here. Do you mean it works without complaining for you? In the past I have deleted all the Products that were in the Products Control Panel to fix a similar bug. Is that the case here as well? The other import problem I see is Zope Could not import Products.HTMLDocument Is HTMLDocument a standard product or a 3rd party product? I don't see one in my 2.6 checkout. If it's 3rd part, then I expect it needs to be upgrade to work with 2.6. HTMLDocument is a 3rd party product. Is there a document that says what has changed enough since 2.5.1 that would break products? and how to fix them? This is frustrating... --andy. ___ 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] Crash Burn with Zope 2.6.0a1 and ZEO 2.0a1
Andrew Sydelko wrote: The errors in the log are all about failures to import specific modules. (Let me know if I missed something else.) Failed to import class Splitter from module Products.PluginIndexes.TextIndex.Splitter.ZopeSplitter When I import Products...ZopeSplitter, I see a module with a Splitter attribute bound to a function. I don't understand what you're saying here. Do you mean it works without complaining for you? In the past I have deleted all the Products that were in the Products Control Panel to fix a similar bug. Is that the case here as well? I explained in the Collector how to fix this problem back in March. http://collector.zope.org/Zope/181 -- 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] Crash Burn with Zope 2.6.0a1 and ZEO 2.0a1
AS == Andrew Sydelko [EMAIL PROTECTED] writes: AS On Tue, 18 Jun 2002 11:20:21 -0400 Jeremy Hylton AS [EMAIL PROTECTED] wrote: AS == Andrew Sydelko [EMAIL PROTECTED] writes: AS Trying Zope 2.6.0a1 and ZEO 2.0a1. The storage server seemed to AS come up fine, but when trying to start the ZEO client it pretty AS much sucked. It looks like you would have had the same problems without ZEO. It would be helpful if you could try running Zope without ZEO, just with FileStorage. AS Hmm... The first time I copied the 3gig Data.fs over and tried AS to start Zope a few times. After fiddling with the permissions AS of the var directory it finally started, but the Data.fs was AS only 2MB! AS So I copied it again. And once again, the 3gig Data.fs is blown AS away! What am I doing wrong??? What are the permissions of the AS var folder supposed to be? I'm starting Zope with: It wouldn't surprise me if this is a completely unrelated problem. Any chance that the python your using to test doesn't have large file support? Check by importing test.test_largefile. We recently discovered that there's a bad interaction between ZODB and Python without large file support running on a platform that supports large files. In this specific configuration, os.path.exists() returns false for files 2 GB and ZODB creates a new Data.fs. Jeremy ___ 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] Crash Burn with Zope 2.6.0a1 and ZEO 2.0a1
AS == Andrew Sydelko [EMAIL PROTECTED] writes: Failed to import class Splitter from module Products.PluginIndexes.TextIndex.Splitter.ZopeSplitter When I import Products...ZopeSplitter, I see a module with a Splitter attribute bound to a function. AS I don't understand what you're saying here. Do you mean it works AS without complaining for you? In the past I have deleted all the AS Products that were in the Products Control Panel to fix a AS similar bug. Is that the case here as well? The problem is that the alpha release had a bug that made it impossible to load Splitter objects from the database. Andreas fixed the bug on Monday, so you could copy the changed file Zope/lib/python/Products/PluginIndexes/TextIndex/Splitter/ZopeSplitter/__init__.py or you could delete whatever objects are related to the text index. The other import problem I see is Zope Could not import Products.HTMLDocument Is HTMLDocument a standard product or a 3rd party product? I don't see one in my 2.6 checkout. If it's 3rd part, then I expect it needs to be upgrade to work with 2.6. AS HTMLDocument is a 3rd party product. Is there a document that AS says what has changed enough since 2.5.1 that would break AS products? and how to fix them? The traceback in the log indicates that the problem is related to InterfaceBase. (IIRC, I don't have that browser window open any more.) I think that Jim changed the Interface package just before the alpha, backporting changes from the Zope3 package. Maybe Jim can summarize what people need to do to update their code. AS This is frustrating... I agree that it is frusterating, but I think it's hard to have an alpha release that works perfectly with all known third party extensions. Jeremy ___ 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] RFC 2616, side effects, and idempotence (was:Last-Modified....)
On Tue, 18 Jun 2002, Oliver Bleutgen wrote: First, your quoting is wrong, I didn't write that - talk about precisionist *g*. Check the number of s. I don't know who lost the attribution of the inner part, but I just replied to your message and cut off everything after the last line quoted. The joys of email grin. But, there's also the attribute safe, which is described in 9.1.1: [...] Which is IMO exactly what we were talking about in that thread. Good point. Perhaps it is. I don't know the areas of the code where you have seen that, but it might be inspired not by the problem of idempotence, but of safeness It's not in the one example I could quote you, in Z3 (some hoops Casey jumped through to try to get the first call to look up a non-existent annotation in an AttributeAnnotatable from causing a ZODB write). But in other cases it might well be. In light of the hit counter use case, safety probably is much more important than idempotence. --RDM ___ 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] problems with accented characters - need advice
There is a function defined in ObjectManager.py called checkValidId. You could override this to enforce certain rules either in a subclass of OM (overridding _setObject) or by a direct monkey patch of ObjectManager.py. Then it would not be possible to supply invalid names from anywhere (ZMI, DAV, FTP or programmatically). hth, -Casey On Tue, 2002-06-18 at 13:08, Eric Brun wrote: hello, we are looking for a simple solution to ensure that objects added to the zope database have valid names... including those which start out containing accented characters ( we are in europe ). we are considering making the change in our PUT, located in NullResource.py in the webdav area. we are wondering if anyone has any comments about this solution... is it a good idea. anyone have any other ideas? we have a process method for correcting accented characters and is located in the constructor of the object class : it works like ob.id = processID(name) here is the change...we have added 'ob.id or name' to setObject method request. code starts here # Delegate actual PUT handling to the new object. ob.PUT(REQUEST, RESPONSE) self.__parent__._setObject(ob.id or name, ob) Eric Brun Savoie Technologie Savoie Technolac ___ 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] Crash Burn with Zope 2.6.0a1 and ZEO 2.0a1
Jeremy Hylton wrote: We recently discovered that there's a bad interaction between ZODB and Python without large file support running on a platform that supports large files. In this specific configuration, os.path.exists() returns false for files 2 GB and ZODB creates a new Data.fs. Wow... bad is not a strong enough word for this bug, especially if you run into it without a backup. How about harrowing. ;-) Shane ___ 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] Last-modified and bobobase_modification_time
Wei He writes: ... 2. From the website developers' point of view, there are already many guidlines on how to create a good webpage. Among them are using the HTTP Last-modification header to take the advantages of client cache. I think you overestimate the importance of accurate Last-Modified headers. In order for caching to be allowed, there must either be a Last-Modified or (alternatively) an Etag header. However, the value of the Last-Modified is almost irrelevant for caching. I think, it is only used when a HTTP cache validates on object, in that is uses this date in an If-Modified-Since request. I would use Expires and Cache-Control for cache control. Dieter ___ 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] problems with accented characters - need advice
Eric Brun writes: we are looking for a simple solution to ensure that objects added to the zope database have valid names... including those which start out containing accented characters ( we are in europe ). I would get rid of the id restriction... In fact, there is no real reason that Zope ids must be valid URL path elements. The reason why it is still there is that a change should work for all languages and not only western ones. This poses the question how the byte string representing the id your should be URL quoted. A good solution must probably wait until Zope id's are Unicode strings. Dieter ___ 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] Crash Burn with Zope 2.6.0a1 and ZEO 2.0a1
On Tue, 18 Jun 2002 12:19:19 -0400 Jeremy Hylton [EMAIL PROTECTED] wrote: It wouldn't surprise me if this is a completely unrelated problem. Any chance that the python your using to test doesn't have large file support? Check by importing test.test_largefile. Yeah, you're right, I don't have largefile support. But I normally don't need it because it's just a ZEO client. And I've been trying to get python to compile with largefile support and I can't. I'm using Debian woody (and no, I don't want to use the installed python2.1 package). Can someone tell me exactly how to compile python 2.1.3 with LFS support? We recently discovered that there's a bad interaction between ZODB and Python without large file support running on a platform that supports large files. In this specific configuration, os.path.exists() returns false for files 2 GB and ZODB creates a new Data.fs. Yeah, that's a bad thing. I'm glad this wasn't my only copy (although it takes 15 minutes to get a new copy since it's so large.) --andy. ___ 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] Crash Burn with Zope 2.6.0a1 and ZEO 2.0a1
AS == Andrew Sydelko [EMAIL PROTECTED] writes: AS Can someone tell me exactly how to compile python 2.1.3 with LFS AS support? I don't have the URL handy, but it's section 8.1.1 of the manual IIRC. Look for large file support in the library reference. Worked for me without problem on a RH 7.2 system. Jeremy ___ 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] Crash Burn with Zope 2.6.0a1 and ZEO 2.0a1
On Tue, 18 Jun 2002 23:01:57 -0400 Jeremy Hylton [EMAIL PROTECTED] wrote: AS == Andrew Sydelko [EMAIL PROTECTED] writes: AS Can someone tell me exactly how to compile python 2.1.3 with LFS AS support? I don't have the URL handy, but it's section 8.1.1 of the manual IIRC. Look for large file support in the library reference. Worked for me without problem on a RH 7.2 system. Yeah, and it's not working for me. I will try some more tomorrow... An earlier question was: What are the correct permissions for the Zope/var folder with a startup of python z2.py -u httpd --andy. ___ 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] Last-modified and bobobase_modification_time
On Tue, 18 Jun 2002, Dieter Maurer wrote: Wei He writes: ... 2. From the website developers' point of view, there are already many guidlines on how to create a good webpage. Among them are using the HTTP Last-modification header to take the advantages of client cache. I think you overestimate the importance of accurate Last-Modified headers. Perhaps. But I think Etag, If-Modified-Since or whatever headers only make sense to a cache server that is designed to use these values, not for a generic one or the end users browser clients. And the last one is the real place caching-related headers making sence to. If I understand correctly, the Expires header can only give the client an impression how ofter a page is updated. I would use Expires and Cache-Control for cache control. Only when you want to disable the cache function, can these two headers be useful. Wei He ___ 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 )
