Re: [Zope-dev] _p_deactivate() and _v_ variables?
Casey Duncan wrote: I would argue that a better plan would be to only use _v_ vars for completely disposable data only. The application should expect that this values will be gone at any random time, not just at transaction boundaries. Agreed. Are there any situations, apart from the already discussed CMF skindata, where this currently isn't the case? Chris ___ 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] _p_deactivate() and _v_ variables?
Dieter Maurer wrote: Chris Withers wrote at 2003-10-8 21:22 +0100: Casey Duncan wrote: I would argue that a better plan would be to only use _v_ vars for completely disposable data only. The application should expect that this values will be gone at any random time, not just at transaction boundaries. I agree with this. How do we go about find code that uses the assumption that _v_ stuff won't change unless it's at a transaction boundary? This will invalidate many current uses: * use for database connections Not really, I would expect a DA to just re-connect if it got garbage collected... * use for skin data This seems to be considered a bug... * ... How do we go about finding these? ;-) Chris ___ 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] Very fast requests beating ZODB commits...
Tres Seaver wrote: Its funny nonetheless that you should report such a thing: we have a customer who reports similar issues in a bit of their CMS, where a popup submits its form (in Javascript) and then refreshes its parent window; if the commit takes long enough (e.g., it hits a conflict), the parent can end up showing the old data after the refresh. Damn these concurrent transactional object databases ;-) Chris ___ 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-CMF] Re: [Zope-dev] _p_deactivate() and _v_ variables?
Toby Dickenson wrote: Today we have the 'transaction participant' interface. That would be a better place to hold these things, allowing the DA object itself to be deactivated if necessary. What's the 'transaction participant interface' and where can I find otu mroe about it? Chris ___ 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] _p_deactivate() and _v_ variables?
On Wednesday 15 October 2003 12:47, Chris Withers wrote: Casey Duncan wrote: I would argue that a better plan would be to only use _v_ vars for completely disposable data only. The application should expect that this values will be gone at any random time, not just at transaction boundaries. Agreed. Are there any situations, apart from the already discussed CMF skindata, where this currently isn't the case? every database adapter? (I guess, but havent checked) -- Toby Dickenson ___ 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] _p_deactivate() and _v_ variables?
Chris Withers wrote: Casey Duncan wrote: I would argue that a better plan would be to only use _v_ vars for completely disposable data only. The application should expect that this values will be gone at any random time, not just at transaction boundaries. Agreed. Are there any situations, apart from the already discussed CMF skindata, where this currently isn't the case? I'm a bit puzzled - of what use is a variable which may disappear at any random time? seb ___ 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] manage_workspace changes
Hi! As also mentioned here http://mail.zope.org/pipermail/cmf-checkins/2003-October/003702.html some CMF tool tabs are broken if used with a current Zope-2_6-branch checkout. I didn't spend much time to find out what's really going on here, so I might be missing something. But it looks like the fix for http://collector.zope.org/Zope/1058 (regarding an PropertySheets issue) causes this bug. Can anybody confirm this? Or has anybody an other idea which recent change could cause the problem? Was it really necessary to break backwards compatibility? Thanks, Yuppie ___ 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] _p_deactivate() and _v_ variables?
Seb Bacon wrote: Agreed. Are there any situations, apart from the already discussed CMF skindata, where this currently isn't the case? I'm a bit puzzled - of what use is a variable which may disappear at any random time? For caching things... Chris ___ 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] _p_deactivate() and _v_ variables?
Seb Bacon wrote: Chris Withers wrote: Casey Duncan wrote: I would argue that a better plan would be to only use _v_ vars for completely disposable data only. The application should expect that this values will be gone at any random time, not just at transaction boundaries. Agreed. Are there any situations, apart from the already discussed CMF skindata, where this currently isn't the case? I'm a bit puzzled - of what use is a variable which may disappear at any random time? It's not exactly random. It would happen when the object was deactivated (removed from cache). If the object is marked as changed (ala _p_changed=1) then its __getstate__ will be called before it is deactivated. If it hasn't changed though then it doesn't really get a chance to do anything about it. Deactivation only happens AFAIK at transaction or subtransaction boundaries. This gives at least some predictability, since subtransactions are rarely used. Perhaps this is why database adapters have been historically incompatible with subtransactions? It seems to me that DAs are a bit broken with regard to where they store their database connection objects. They should register an object with the transaction that holds the connection so that it can be properly committed or aborted regardless of what happens with _v_ variables in the interim. -Casey ___ 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] _p_deactivate() and _v_ variables?
On Wednesday 15 October 2003 14:53, Casey Duncan wrote: Agreed. Are there any situations, apart from the already discussed CMF skindata, where this currently isn't the case? I'm a bit puzzled - of what use is a variable which may disappear at any random time? It's not exactly random. It would happen when the object was deactivated (removed from cache). The proposal earlier in the thread was aiming towards allowing objects to get deactivated at any time if the cache was overfull, not just at transaction boundaries. This is desirable from a cache management point of view. Apart from the most trivial cases, it would allow _v_ attributes to disappear at random. Its a similar problem to the one that makes it hard to write an optimiser for python code, and I am unconvinced that this is sane. -- Toby Dickenson ___ 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] WebDAV and UTF-8 filenames
Hi guys! I've been hacking around a bit with Zope to try to support some non-ascii characters in the id's. Yes, I know it looks ugly in the URL's but when you go via WebDAV, that is not an issue. :) Anyhow, getting your Zope-object to accept non-ascii characters is not that hard, of course. But the problem comes when you try to use OpenOffice, and do a Save As It seems like OpenOffice sends the new name as UTF-8, translating a nice filé.doc to filé.doc. Of course, OpenOffice will translate it back, so it looks good in OpenOffice, but that the id is different from the webclient and OpenOffice is not a good idea. Could somebody help me shed some light on some issues here: 1. Does this happen because Zope missed out on UTF-8 decoding and encoding somewhere? It seems to me that this should be done in the ZPublisher somewhere, but it isn't, right? 2. I have tried understanding the ZPublisher before, but failed. Can somebody point me to where this decoding encoding should be done, maybe? Or are you of the opinion that it's to complicated a bug to fix? 3. Will Zope 2.7 be Python 2.3 only? Because that would probably make UTF-8 support easier. //Lennart ___ 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] _p_deactivate() and _v_ variables?
Toby Dickenson wrote: On Wednesday 15 October 2003 14:53, Casey Duncan wrote: Agreed. Are there any situations, apart from the already discussed CMF skindata, where this currently isn't the case? I'm a bit puzzled - of what use is a variable which may disappear at any random time? It's not exactly random. It would happen when the object was deactivated (removed from cache). The proposal earlier in the thread was aiming towards allowing objects to get deactivated at any time if the cache was overfull, not just at transaction boundaries. This is desirable from a cache management point of view. Apart from the most trivial cases, it would allow _v_ attributes to disappear at random. Its a similar problem to the one that makes it hard to write an optimiser for python code, and I am unconvinced that this is sane. I agree. If objects disappeared from cache randomly, I think the system as a whole would not be stable or predictable. I also think it would tend to make a loaded server even more loaded by thrashing the cache unnecessarily. As it is, the hard cache implementation, although beneficial from a memory management perspective cause loaded servers to do alot more work because they are constantly pruning the cache and then reloading objects again immediately thereafter. It might be worth considering a more gradual cache mgmt policy which has a target size, a maximum size and a prune rate. Currently, we have only a maximum size. Then again, since Python never really returns memory to the OS, I'm not sure it matters much in the end. -Casey ___ 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] WebDAV and UTF-8 filenames
If you set the management_page_charset property to utf-8 in a folder (even the root folder) then Zope will inform the browser that the charset of the management pages of this folder and all subobjects is utf-8 and the IDs in the folder listing page will look right. Cheers, Leo -- Ideas don't stay in some minds very long because they don't like solitary confinement. ___ 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] _p_deactivate() and _v_ variables?
On Wednesday 15 October 2003 15:51, Casey Duncan wrote: As it is, the hard cache implementation, although beneficial from a memory management perspective cause loaded servers to do alot more work because they are constantly pruning the cache and then reloading objects again immediately thereafter. If you are seening that then I think you need a bigger cache. And possibly fewer publisher threads. -- Toby Dickenson ___ 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] WebDAV and UTF-8 filenames
Leonardo Rochael Almeida wrote: If you set the management_page_charset property to utf-8 in a folder (even the root folder) then Zope will inform the browser that the charset of the management pages of this folder and all subobjects is utf-8 and the IDs in the folder listing page will look right. This does seem to solve the problem (at least with OpenOffice. Cadaver does not like it, but that is probably a Cadaver bug). ___ 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] WebDAV and UTF-8 filenames
On Wed, 2003-10-15 at 12:50, Lennart Regebro wrote: Leonardo Rochael Almeida wrote: If you set the management_page_charset property to utf-8 in a folder (even the root folder) then Zope will inform the browser that the charset of the management pages of this folder and all subobjects is utf-8 and the IDs in the folder listing page will look right. This does seem to solve the problem (at least with OpenOffice. Cadaver does not like it, but that is probably a Cadaver bug). If the does not seem to like it is just a charset display issue, and not an explicit error condition, then this is probably because Cadaver is a command line client, which usually (but not always) means that it's totally obvlivious to charset issues. It'll just spew whatever it receives from the server to your terminal and vice-versa. In this case, it's your terminal's job to interpret utf-8 chars correctly in this case, and to pass accented chars to Cadaver as two byte utf-8 sequences when you type them on the terminal. Cheers, Leo -- Ideas don't stay in some minds very long because they don't like solitary confinement. ___ 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 )
