Re: [Zope-dev] access of non html documents
Hi Roberto, One solution is to provide a temporary identifyer via cookie, which gets set if the user sees your page but is not set if she wants to download it directly. A simple non guessable scrable mechanism using your page url, file url and probably ip of the downloader should do for the cookie value. File objects can have a precondition which refers to a method where you can evaluate the cookie and serve the file or refuse access (via raise Redirect,url) I would not recommend to use HTTP_REFERRER for this, because this is by no way relieable. Regards Tino --On Dienstag, 12. November 2002 16:11 -0800 General Info [EMAIL PROTECTED] wrote: i have the following situation. i want the users to be able to download non html documents if that document is refered to from an html document. however, i dont want the users to be able to type the url and document name on the url box of their browers and be able to download it. for example: the documents exist in http://www.wwwdotcom.com/nonhtmldocs/doc1.pdf however, i dont want the users to type that url on their browser and access doc1.pdf i only want them to access it if that particular document is linked from an html document. i have seen some websites that do that w/ images. how can i do that on zope? is it possible? i would appreciate any comments/suggesstions. -roberto ___ 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] DB.close() needs to be called
On Tuesday 12 November 2002 7:16 pm, Barry A. Warsaw wrote: Looks like Toby's recent change to ApplicationManager.py causes DB.close() to never be called when you hit Shutdown in the Control Panel. Yes. This is a bad thing for the Berkeley storages because their .close() must get called or you'll end up with corrupt databases or worse wink. How much of that paragraph is covered by the wink? Even before my recent changes, there are plenty of other ways that Zope can open the storage, run a transaction, then hit an error before properly starting up which means it fails to close the database correctly. Would this be bad? So here's a patch to z2.py to fix this. I won't check this in because it looks a little ugly to me and I'm not sure what the right fix is, That is exactly what I was planning to commit. Before making that change, I need to remove a couple other calls to db.close() to prevent it being called twice on the same db. but we definitely need to fix this before Zope 2.6.1 is released. 2.6.1? This change has only been on the trunk, not the 2.6 maintenance branch. ___ 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] defining PythonScript custom permission ?
Hi, I'd like to be able to define custom permissions throug ZMI that I can query within a number of PythonScript instancse. The permission should express that a set of PythonScripts are executable. The PythonScript do not return a class so the methode described at Zope Book Class Security Assertions In Non-Product Code (External Methods/Python Scripts) do not fit. I have a Python Workflow Product in mind that allows me to configure a set of customizable PythonScripts. I want the user to be able to create a custom permission that can be used within a set of instances. Normally Globals.InitializeClass does the job. But I'm looking for a way to define permissions at runtime that are bound to a PythonScript in several but not all product instances. Can Permission.registerPermissions be used to do that and is ther a method to unregister permissions? aeg -- ___ Andreas Heckel [EMAIL PROTECTED] LINUX is like a wigwam...no gates...no windows and an apache inside ;-) ___ 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] Strange bug (NOT a Zope bug!) when exporting Zope objects on Windows with Norton Personal Firewall running ...
Hi! I just encountered a very strange bug: One of our clients had problems with exporting and importing his stuff from his local machine to our servers. What happened was that lines like meta name=keywords content=dtml-var keywords became meta name=keywords content=dtml-var keywords and ___ Joachim Werner iuveno AG Wittelsbacherstraße 23b 90475 Nürnberg Tel. +49 (0) 911 / 988398-4 Fax +49 (0) 911 / 988398-5 Mail: [EMAIL PROTECTED] WWW: http://www.iuveno.de ___ 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] Strange bug (NOT a Zope bug!) when exporting Zope objects on Windows with Norton Personal Firewall running ...
Hi! Sorry for the corrupted mail. I just hit some button by accident and the mail was gone ... Here is the full text: I just encountered a very strange bug: One of our clients had problems with exporting and importing his stuff from his local machine to our servers. What happened was that lines like meta name=keywords content=dtml-var keywords became meta name=keywords content=dtml-var keywords and img src=dtml-var imageUrl became img src=dtml-var imageUrl, which of course broke the HTML (I know that one could use the dtml entity syntax instead, but that's not the point here). We didn't have a clue why that would happen and suspected some incompatibility with character sets involved (He was on Windows with Zope 2.5.1 and we had Linux and Zope 2.6.0). But the solution was that as soon as the client had deactivated his Norton Personal Firewall and Norton Antivirus, everything was o.k. again! So this is NOT a Zope bug, but maybe it helps to know about the problem. The Firewall or Antivirus software (we think it is the Firewall) seem to parse the code (regardless whether you do a zexp or xml export) and replace characters ... The funny thing is that this seems to happen even if the Zope server runs locally! Cheers Joachim ___ Joachim Werner iuveno AG Wittelsbacherstraße 23b 90475 Nürnberg Tel. +49 (0) 911 / 988398-4 Fax +49 (0) 911 / 988398-5 Mail: [EMAIL PROTECTED] WWW: http://www.iuveno.de ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [ZODB-Dev] deadlock prevention for ZODB3 / Zope 2.6
Jeremy Hylton wrote: We recently discovered that ZODB3 applications, like Zope 2.6, can deadlock when run in a system that uses multiple storages. This was a fundamental design flaw in ZODB that, happily, has a simple fix. Would this fix also help with this problem: http://sourceforge.net/tracker/index.php?func=detailaid=550246group_id=15628atid=115628 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] DB.close() needs to be called
TD == Toby Dickenson [EMAIL PROTECTED] writes: This is a bad thing for the Berkeley storages because their .close() must get called or you'll end up with corrupt databases or worse wink. TD How much of that paragraph is covered by the wink? The or worse part. If you've enable autopacking and you don't cleanly close the storage, you won't exit the process because the autopack thread won't get stopped and joined. We could make the autopack thread a daemon process, but it makes me nervous to do that in the general case, because if you exit while autopack is running, you could corrupt your database. Hmm, I guess we could make it a daemon process and yet still cleanly stop it on a close()... TD Even before my recent changes, there are plenty of other ways TD that Zope can open the storage, run a transaction, then hit an TD error before properly starting up which means it fails to TD close the database correctly. TD Would this be bad? It wouldn't be good, but remember that we run BerkeleyDB in auto-recovery mode, so it means that the next time you open the database, it will run recovery (you can also run recovery manually). However, depending on your checkpointing policy, and the size of committed data since your last checkpoint, recovery could end up taking a long time. Sure, any number of bad things can happen at any time, and defense against that is one of the benefits of using BerkeleyDB underneath. But under normal operations, we definitely want to exit cleanly. So here's a patch to z2.py to fix this. I won't check this in because it looks a little ugly to me and I'm not sure what the right fix is, TD That is exactly what I was planning to commit. Cool. :) TD Before making that change, I need to remove a couple other TD calls to db.close() to prevent it being called twice on the TD same db. Ok. but we definitely need to fix this before Zope 2.6.1 is released. TD 2.6.1? This change has only been on the trunk, not the 2.6 TD maintenance branch. You're right. I was running from the trunk. Thanks, -Barry ___ 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] DB.close() needs to be called
Maybe normal shutdown should manually call the shutdown signal handler function and normal restart should manually call the restart signal handler function? On Wed, 2002-11-13 at 10:28, Toby Dickenson wrote: On Wednesday 13 November 2002 2:10 pm, Barry A. Warsaw wrote: TD == Toby Dickenson [EMAIL PROTECTED] writes: This is a bad thing for the Berkeley storages because their .close() must get called or you'll end up with corrupt databases or worse wink. TD How much of that paragraph is covered by the wink? The or worse part. If you've enable autopacking and you don't cleanly close the storage, you won't exit the process because the autopack thread won't get stopped and joined. Yes, I had the same problem with DirectoryStorage, which uses a seperate thread to move writes from its journal directory into the database directory. We could make the autopack thread a daemon process Thats how DirectoryStorage now works. It wouldn't be good, but remember that we run BerkeleyDB in auto-recovery mode, so it means that the next time you open the database, it will run recovery (you can also run recovery manually). However, depending on your checkpointing policy, and the size of committed data since your last checkpoint, recovery could end up taking a long time. Last time I looked at your BerkeleyDB storages, the administrator needed to implement his own checkpointing policy. I always thought that was a disadvantage. Would it now be a good idea for the storages to trigger their own checkpointing inside the autopacker thread? Sure, any number of bad things can happen at any time, and defense against that is one of the benefits of using BerkeleyDB underneath. But under normal operations, we definitely want to exit cleanly. Agreed, on both points. ___ 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] DB.close() needs to be called
Nevermind. I see what Toby did in the signals module and it makes sense. On Wed, 2002-11-13 at 11:01, Chris McDonough wrote: Maybe normal shutdown should manually call the shutdown signal handler function and normal restart should manually call the restart signal handler function? On Wed, 2002-11-13 at 10:28, Toby Dickenson wrote: On Wednesday 13 November 2002 2:10 pm, Barry A. Warsaw wrote: TD == Toby Dickenson [EMAIL PROTECTED] writes: This is a bad thing for the Berkeley storages because their .close() must get called or you'll end up with corrupt databases or worse wink. TD How much of that paragraph is covered by the wink? The or worse part. If you've enable autopacking and you don't cleanly close the storage, you won't exit the process because the autopack thread won't get stopped and joined. Yes, I had the same problem with DirectoryStorage, which uses a seperate thread to move writes from its journal directory into the database directory. We could make the autopack thread a daemon process Thats how DirectoryStorage now works. It wouldn't be good, but remember that we run BerkeleyDB in auto-recovery mode, so it means that the next time you open the database, it will run recovery (you can also run recovery manually). However, depending on your checkpointing policy, and the size of committed data since your last checkpoint, recovery could end up taking a long time. Last time I looked at your BerkeleyDB storages, the administrator needed to implement his own checkpointing policy. I always thought that was a disadvantage. Would it now be a good idea for the storages to trigger their own checkpointing inside the autopacker thread? Sure, any number of bad things can happen at any time, and defense against that is one of the benefits of using BerkeleyDB underneath. But under normal operations, we definitely want to exit cleanly. Agreed, on both points. ___ 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 ) ___ 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] DB.close() needs to be called
On Wednesday 13 November 2002 4:01 pm, Chris McDonough wrote: Maybe normal shutdown should manually call the shutdown signal handler function and normal restart should manually call the restart signal handler function? We are pretty close to that now, which I agree is a good thing. The shutdown signal handler is now a one-liner that calls Lifetime.shutdown. The ZMI handler is a two-liner that calls the same function, then returns some html. Lifetime.shutdown causes the asyncore select loop to return (possibly after a brief pause to allow clients to disconnect cleanly), and z2.py closes the databases (and hence storages) as its very last action. ___ 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] DB.close() needs to be called
TD == Toby Dickenson [EMAIL PROTECTED] writes: worse part. If you've enable autopacking and you don't cleanly close the storage, you won't exit the process because the autopack thread won't get stopped and joined. TD Yes, I had the same problem with DirectoryStorage, which uses TD a seperate thread to move writes from its journal directory TD into the database directory. Ah. Is this transactional? What would happen if the thread got killed in the middle of the move? We could make the autopack thread a daemon process TD Thats how DirectoryStorage now works. Hmm, maybe we make it a daemon thread and put a timeout on the join, so we'll try to exit cleanly and won't hang if we can't. Autopacking should be safe transactionally, but we'd have to do a recovery if it got killed uncleanly. It wouldn't be good, but remember that we run BerkeleyDB in auto-recovery mode, so it means that the next time you open the database, it will run recovery (you can also run recovery manually). However, depending on your checkpointing policy, and the size of committed data since your last checkpoint, recovery could end up taking a long time. TD Last time I looked at your BerkeleyDB storages, the TD administrator needed to implement his own checkpointing TD policy. I always thought that was a disadvantage. Would it now TD be a good idea for the storages to trigger their own TD checkpointing inside the autopacker thread? Actually, now you can configure the storages to automatically checkpoint every nth ZODB transaction. Checkpointing in a thread may or may not provide additional benefit. Sure, any number of bad things can happen at any time, and defense against that is one of the benefits of using BerkeleyDB underneath. But under normal operations, we definitely want to exit cleanly. TD Agreed, on both points. Cool. -Barry ___ 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] DB.close() needs to be called
(cc zodb-dev, who may also be interested) On Wednesday 13 November 2002 4:18 pm, Barry A. Warsaw wrote: TD == Toby Dickenson [EMAIL PROTECTED] writes: worse part. If you've enable autopacking and you don't cleanly close the storage, you won't exit the process because the autopack thread won't get stopped and joined. TD Yes, I had the same problem with DirectoryStorage, which uses TD a seperate thread to move writes from its journal directory TD into the database directory. Ah. Is this transactional? What would happen if the thread got killed in the middle of the move? There are lots of ways to look at that question I am relying on the filesystem guarantee that the files are all either in their original directory, or their new directory. DirectoryStorage has its equivalent of BerkeleyStorage's autorecovery which, at startup, asynchronously resumes the file moving wherever it left off. A more interesting question is what happens if the thread is killed when it has moved some, but not all, of the files which relate to one transaction. In DirectoryStorage terminology this leaves the data directory in a state which is not a snapshot. The only disadvantage is that you can not use the tools which assume the data directory is a snapshot: the checking tool, the incremental back tool, and the replication tool. We could make the autopack thread a daemon process TD Thats how DirectoryStorage now works. Hmm, maybe we make it a daemon thread and put a timeout on the join, so we'll try to exit cleanly and won't hang if we can't. Because some of the operations performed in the daemon thread take a long time to complete? Would it be possible to break those operations into transactionally-coherent chunks which complete in a reasonable time? close() could wait for the current chunk to finish. Autopacking should be safe transactionally, but we'd have to do a recovery if it got killed uncleanly. Doesnt having a good checkpointing strategy mean that this should never take long? TD Last time I looked at your BerkeleyDB storages, the TD administrator needed to implement his own checkpointing TD policy. I always thought that was a disadvantage. Would it now TD be a good idea for the storages to trigger their own TD checkpointing inside the autopacker thread? Actually, now you can configure the storages to automatically checkpoint every nth ZODB transaction. Checkpointing in a thread may or may not provide additional benefit. Interesting. BerkeleyStorage's automatic checkpointing is currently triggered inside a commit or abort. This means the checkpoint overhead is incurred at the one time you dont want it - while a user is waiting for his transaction to commit. DirectoryStorage's main use for the thread is to perform its equivalent asynchronously. Assuming your storage is not saturated with writes (which only happens in benchmarks ;-) then checkpointing happens for free. ___ 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: [ZODB-Dev] Re: [Zope-dev] DB.close() needs to be called
TD == Toby Dickenson [EMAIL PROTECTED] writes: What would happen if the thread got killed in the middle of the move? TD A more interesting question is what happens if the thread is TD killed when it has moved some, but not all, of the files which TD relate to one transaction. That's more what I was thinking about. TD In DirectoryStorage terminology this leaves the data directory TD in a state which is not a snapshot. The only disadvantage is TD that you can not use the tools which assume the data directory TD is a snapshot: the checking tool, the incremental back tool, TD and the replication tool. Interesting. Berkeley storage has something similar. Let's say the storage crashes in the middle of tpc_vote() or tpc_finish(). First, BerkeleyDB's recovery should clean up any of its corrupt transactions. Then the storage has its own recovery process for the current transaction, i.e. the one we were in the middle of at the time of the crash. Depending on when the crash occurred, the storages will either commit or abort the current transaction (if the crash happened in tpc_finish(), we'll complete the commit, otherwise we abort the transaction). So I believe -- although this isn't battle tested -- that the Berkeley storages should be pretty safe against inconsistency and corruption. We could make the autopack thread a daemon process TD Thats how DirectoryStorage now works. Hmm, maybe we make it a daemon thread and put a timeout on the join, so we'll try to exit cleanly and won't hang if we can't. TD Because some of the operations performed in the daemon thread TD take a long time to complete? Potentially yes, although the steps in the pack process are BerkeleyDB transactionally protected. I think the mark-and-sweep phases are examples of things that could take a long time. It should be possible to craft some escape hatches to do a more controlled shutdown. TD Would it be possible to break those operations into TD transactionally-coherent chunks which complete in a reasonable TD time? close() could wait for the current chunk to finish. Yep. Autopacking should be safe transactionally, but we'd have to do a recovery if it got killed uncleanly. TD Doesnt having a good checkpointing strategy mean that this TD should never take long? I think checkpointing itself is a trade-off between the length of time it takes to checkpoint and the length of time it could potentially take to recover. TD Last time I looked at your BerkeleyDB storages, the TD administrator needed to implement his own checkpointing TD policy. I always thought that was a disadvantage. Would it now TD be a good idea for the storages to trigger their own TD checkpointing inside the autopacker thread? Actually, now you can configure the storages to automatically checkpoint every nth ZODB transaction. Checkpointing in a thread may or may not provide additional benefit. TD Interesting. BerkeleyStorage's automatic checkpointing is TD currently triggered inside a commit or abort. This means the TD checkpoint overhead is incurred at the one time you dont want TD it - while a user is waiting for his transaction to TD commit. DirectoryStorage's main use for the thread is to TD perform its equivalent asynchronously. Assuming your storage TD is not saturated with writes (which only happens in benchmarks TD ;-) then checkpointing happens for free. That's a very interesting idea! Hmm, checkpoint in a thread. Yeah, that sounds much better, although I'm mildly concerned with concurrancy issues, especially given that we don't use the BerkeleyDB locking subsystem. I'll have to read up on the docs, but it's a good idea. -Barry ___ 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: [ZODB-Dev] Re: [Zope-dev] DB.close() needs to be called
On Wednesday 13 November 2002 5:27 pm, Barry A. Warsaw wrote: Potentially yes, although the steps in the pack process are BerkeleyDB transactionally protected. I think the mark-and-sweep phases are examples of things that could take a long time. It should be possible to craft some escape hatches to do a more controlled shutdown. Yes, DirectoryStorage's referential integrity rules had to be carefully crafted to ensure that it can bomb out of a pack at short notice. ___ 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] Contents of Initial Data.fs in Zope Distribution?
Working on updating my ZOPE and ZEO RPMs I got to wondering... What's in the default data.fs that ships with Zope? I mean, ZEO (actually ZODB) auto-creates a data.fs when one isn't found, so why does Zope come with one? Or if there -is- something Zope-specific in data.fs, then shouldn't there be a warning in the ZEO notes that when ZEO is used _underneath_ Zope, be sure to copy the data.fs that comes with it? My experience has always been with ZEO and StandaloneZODB, not ZEO+Zope so I'm puzzled. -Jeff ___ 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] Contents of Initial Data.fs in Zope Distribution?
It is only there due to lack of time to take it out. We had planned to take it out for 2.6, but time was never made to replace it with code to bootstrap an empty storage with the proper root level elements still residing in Data.fs.in. -Casey On Wednesday 13 November 2002 02:22 pm, Jeff Rush wrote: Working on updating my ZOPE and ZEO RPMs I got to wondering... What's in the default data.fs that ships with Zope? I mean, ZEO (actually ZODB) auto-creates a data.fs when one isn't found, so why does Zope come with one? Or if there -is- something Zope-specific in data.fs, then shouldn't there be a warning in the ZEO notes that when ZEO is used _underneath_ Zope, be sure to copy the data.fs that comes with it? My experience has always been with ZEO and StandaloneZODB, not ZEO+Zope so I'm puzzled. -Jeff ___ 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 )
[Zope-dev] HTTP content negotiation-- has anyone tried this in Zope?
Hello: I try to keep tabs on other open source CMSs, in particular Apache Cocoon, and I noticed this message: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=103717736917834w=2 talking about software that, in effect, enables one to configure a server to respond to the HTTP headers having to do with content negotiation: preferred charset, preferred language, and content-type. This is way cool stuff-- imagine an application capable of returning an XML representation of a resource instead of a human-readable XHTML simply based on the HTTP header-- same URL. ASIDE: This is in line with TBL's original vision of the web and is being adopted by high profile organizations like google-- it has supported Accept-Language for at least a year-- change the list of acceptable languages to demonstrate it in a browser... Question: has anyone tried to support this kind of thing using Zope yet? I imagine it should be possible, b/c you should have access to everything you need in the REQUEST object, right? If one agrees that this is a good idea, then wouldn't it be cool to have a set of ready-made components in Zope3 to facilitate switching on relevant HTTP headers-- either for mime type, I18N, etc.? Thoughts? --Craeg ___ 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] HTTP content negotiation-- has anyone tried this in Zope?
On Wed, 13 Nov 2002 16:14:11 -0800 Craeg Strong [EMAIL PROTECTED] wrote: Hello: talking about software that, in effect, enables one to configure a server to respond to the HTTP headers having to do with content negotiation: preferred charset, preferred language, and content-type. Question: has anyone tried to support this kind of thing using Zope yet? I imagine it should be possible, b/c you should have access to everything you need in the REQUEST object, right? If one agrees that this is a good idea, then wouldn't it be cool to have a set of ready-made components in Zope3 to facilitate switching on relevant HTTP headers-- either for mime type, I18N, etc.? As far as I know, Zope3 already has some implementation of content negotiation mechanism regarding with: preferred-language and preferred charset There's some description about it: http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/LanguageNegotiationFramework I have implemented experimental multilingual locale support for Zope 2.5.1 which will manipulate Content-Type header (I haven't disclosed it yet though). --- Heiichiro NAKAMURA [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] HTTP content negotiation-- has anyone tried this in Zope?
Hi! We've talked a lot about that when we discussed Zope I18N some time ago. Most of this is relatively easy to accomplish even now. Regarding language negotiation: Both Localizer and ZBabel do this. The problem in my practical experience is that most people do not configure their browsers correctly. This is especially true with people having English instead of localized browser versions (e.g. in large corporations), but at the same time not expecting to get The Web in English only ... -- I hope that this will change ... With regard to content type: I had a proposal some time ago that I still think to be cool, but that didn't get too much attention: If we used object names without any .whatever suffixes, we could easily provide handlers for different output formats. An example: Let's say you upload an OpenOffice text file in XML format. It is called myFile.sxw. It will actually be stored as a folderish object called myFile that contains all the items of an OpenOffice file (which is a zipped folder of content, stylesheet, and image files). You could then retrieve it as HTML, using myFile.sxw, as a MS Word document, using myFile.doc, etc. etc. This might not be the right thing as a Zope default. But in a document management context this would just be marvelous. The decision what file format to return could be handled via content type negotiation, or via an explizit URL containing the suffix. The only thing that still is not quite obvious to me is how to handle FTP or WebDAV requests. One could display ALL options, or just the default one. I try to keep tabs on other open source CMSs, in particular Apache Cocoon, and I noticed this message: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=103717736917834w=2 talking about software that, in effect, enables one to configure a server to respond to the HTTP headers having to do with content negotiation: preferred charset, preferred language, and content-type. This is way cool stuff-- imagine an application capable of returning an XML representation of a resource instead of a human-readable XHTML simply based on the HTTP header-- same URL. ASIDE: This is in line with TBL's original vision of the web and is being adopted by high profile organizations like google-- it has supported Accept-Language for at least a year-- change the list of acceptable languages to demonstrate it in a browser... Question: has anyone tried to support this kind of thing using Zope yet? I imagine it should be possible, b/c you should have access to everything you need in the REQUEST object, right? If one agrees that this is a good idea, then wouldn't it be cool to have a set of ready-made components in Zope3 to facilitate switching on relevant HTTP headers-- either for mime type, I18N, etc.? Thoughts? --Craeg ___ 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] Contents of Initial Data.fs in Zope Distribution?
I don't quite understand -- so there *are* root level elements specific to Zope that need to be copied into a Zope-over-ZEO environment? (hm, how do those elements get into a non-FileStorage Zope-over-ZEO environment?) And do those elements interfere even a little in a non-Zope-just-ZEO environment? The only way I can imagine, other than simplistic name clashes would be if a full iteration of such a ZODB would cause unghosting of objects lacking Zope .pyc and raise unnecessary exceptions. I ask because I'm trying to decide whether two ZEO RPMs are needed re ZEO-wo-Zope-2.0-1.i386.rpm and ZEO-w-Zope-2.0-1.i386.rpm, or just one. Somewhat similar to how the Zope RPMs have separate ZServer and PCGI flavor packages. -Jeff Rush Casey Duncan wrote: It is only there due to lack of time to take it out. We had planned to take it out for 2.6, but time was never made to replace it with code to bootstrap an empty storage with the proper root level elements still residing in Data.fs.in. -Casey On Wednesday 13 November 2002 02:22 pm, Jeff Rush wrote: Working on updating my ZOPE and ZEO RPMs I got to wondering... What's in the default data.fs that ships with Zope? I mean, ZEO (actually ZODB) auto-creates a data.fs when one isn't found, so why does Zope come with one? Or if there -is- something Zope-specific in data.fs, then shouldn't there be a warning in the ZEO notes that when ZEO is used _underneath_ Zope, be sure to copy the data.fs that comes with it? My experience has always been with ZEO and StandaloneZODB, not ZEO+Zope so I'm puzzled. -Jeff ___ 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] SSL Server integrated to Zope
Hi! I try to hack SSL Server integreted to Zope. http://www.zope.org/Members/nakagami/zSSL #I wan't to use M2Crypto, Because It's difficult to me. I don't have enoght test, And I only tested on Cygwin. But I think zSSL good for several platform and some version (Probably 2.5 and later) of Zope. Please someone test that and send comment to me. PS. I have heard from a Linux Box user that when large page saved, zSSL came to stop. Is it blocking I/O ? race condition ?, please someone teachme. ___ 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 )
