Re: [Zope-dev] two-phase-commit question
Kapil Thangavelu wrote: ZOPE_HOME/lib/python/Shared/DC/ZRDB/TM.py Glancing over the Transaction TM mixin class... i noticed a line commit=tpc_abort=tpc_begin i can understand tpc_begin=commit, but the abort seems strange. if an abort happens in the two phase commit the equality doesn't make sense to me. whats going on here? Is this meant to be overidden? Yes. Override the methods that you need to. The rest are given a no-operation default implementation. The class more or less defines an interface. def tpc_begin(self, *ignored): pass commit=tpc_abort=tpc_begin The assignment you see is just a short-hand way of saying that commit, tpc_abort and tpc_begin have the same method signature and the same implementation -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net ___ 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] How is 'retrieveItem intended to work with TTW Specialists?
Thanks again... it's great that you're willing to entertain my apparantly twisted use of ZPatterns. ;-) "PJE" == Phillip J Eby [EMAIL PROTECTED] writes: PJE To put it another way: design your whitebox specialist how PJE you want it. Make it complete, but of course some parts will PJE have to be changed if someone wants to use other than your PJE default implementation. If they want its data to come from PJE somewhere else, they can plug in the SkinScript or do PJE whatever else it takes. PJE So, to sum up... Stop worrying about delegated retrieval! PJE :) You're stepping into app integrator territory here. PJE ZPatterns was designed to make it easy to make reusable PJE frameworks without hardly trying. And it was *especially* PJE designed for retrofitting object frameworks over legacy PJE applications and databases. Hmm... OK I see what you mean. I guess I somehow got the idea that ZPatterns worked best when you had two ZPatterns based frameworks that you wanted to work together *after* they had both been designed. I was looking for a way to 'hook up' two 'finished' applications. I was trying to avoid creating a framework that couldn't be easily integrated, by attemting a 'fake' integration myself. How can I be sure I've got all the TTW stuff organized in a way that an integrator can change unless I actually set it up and test it that way? I'd hate to find out later that someone needs to go in and edit my Python code to make my framework useable But.. I think what I'm hearing is that working out the integration at the Rack level is much better than trying to delgate retrieval at the Specialist level. I'm not sure where I got the idea that delegating retrieval at the Specialist level was the 'right' way, maybe in the Drop Zone example? Anyway... thanks again for your reply. I'll march happily along now and see what I run into next! ;-) (I'm especially grateful for your explaination of using a virtual object (non-persistent) in a Rack. I've not seen that explained so clearly anywhere else.. and I'm going to use it! thanks! -steve ___ 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] Membership and PTK
I am getting married Monday, and may be off lists for a week, so for anyone who has done _any_ Membership/PTK Integration, PLEASE, send it to me now, so I can work on it over the weekend, and next week. I don't want to duplicate work already done. Bill -- E PLURIBUS LINUX ___ 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] CoreSessionTracking proposal
I just read the CoreSessionTracking proposal. I am very concerned about the "long living browser id". * Why should a browser id live longer than the session data maintained for the browser? This means, if the session lifetime is in the order of an hour, the cookie need not live longer than, say, a day. * I am *VERY* suspicious whenever I get a cookie with an expiration date more than a few days in the future. I do not see any reason why a site should be able to track my activity over a longer period of time -- at least no without my explicit consent. I tend to refuse long living cookies and as sites continue to send cookies on any request, I disable cookies all together. If this means, a site can not be visited, I stop visiting the site. If Zope tries to implement long living browser ids, I fear, Zope sites will have a high chance, I will no longer visit them. Security: * I do not think "Annonymous" should have the permission "Add Session Data Objects". Session handling should be transparent, including allocation of a session data object. * I do not think "Annonymous" should have "Access Session Data" permission with the exception to its own session data. Sessions may contain confident information that must not be revealed to other users. Again, session handling should be transparent, implemented by a mechanism that implements its own special purpose access policy (access to session data only by the session owner). Consistency: * sometimes "__zsession__" and sometime "_ZopeId" seems to be used to refer to an identifier used for session tracking * how is it possible to have nested "Session ID Managers" (necessary for delegation) with "getZopeSessionID" a singleton? As I understand it, the "singleton" property prevents any child to reimplement the method. I must be wrong with this assumption. 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 )
[Zope-dev] Re: CoreSessionTracking proposal
I just read the CoreSessionTracking proposal. Great... I am very concerned about the "long living browser id". * Why should a browser id live longer than the session data maintained for the browser? Because it's a browser id, not a session id. This terminology may change in later revisions of the code I've come up with, but this is the basic idea. This means, if the session lifetime is in the order of an hour, the cookie need not live longer than, say, a day. Not if you want to associate a session with a browser across a long period of time. For example, if you wish to maintain a long-lived "wish list" of items in session storage without requiring a user to log in. * I am *VERY* suspicious whenever I get a cookie with an expiration date more than a few days in the future. I do not see any reason why a site should be able to track my activity over a longer period of time -- at least no without my explicit consent. The cookie lifetime is configurable, so this is up to the site manager or developer. This is not a problem endemic to Zope or the core session tracking proposal, but to the configuration imposed by the developer or site manager. Lots of people don't mind long-lived cookies, and it's not realistic to limit the functionality of the system based on something that's out of our scope of influence. If you choose not to visit sites that provide long-lived cookies, then perhaps that site's session manager will choose to reduce the cookie lifetime. Security: * I do not think "Annonymous" should have the permission "Add Session Data Objects". Session handling should be transparent, including allocation of a session data object. The use case description that mentions "add session data objects" is incorrect. That permission will not exist. The overall permission "Access session data" will permit the creation of session data objects, as well as the manipulation of already-created session data objects. Anonymous must be granted this permission (or sessions would be completely worthless, as they would require users to log in). * I do not think "Annonymous" should have "Access Session Data" permission with the exception to its own session data. How do you propose that we recognize one 'Anonymous User' from another? Sessions may contain confident information that must not be revealed to other users. Anonymous session data should not contain confidential information. This is what data storage associated with an authenticated user is for. However, the risk of information release is mitigated somewhat (but not much) by the fact that session ids will have a random element. Additionally, the "access session data" permission can be withheld from users who have the rights to create DTML or other TTW methods, thus disallowing them to manipulate a visitor's session data from this code. Again, session handling should be transparent, implemented by a mechanism that implements its own special purpose access policy (access to session data only by the session owner). This is not possible without authentication. The point of sessions is to allow the developer to associate a namespace across multiple visits by an anonymous user. Requiring a user to authenticate before using sessions defeats the purpose. Consistency: * sometimes "__zsession__" and sometime "_ZopeId" seems to be used to refer to an identifier used for session tracking The identifier is configurable. It should probably start with an underscore to be recognizable as a URL-inlined attribute, but this is up for debate. The ids used within the proposal are only suggestions. * how is it possible to have nested "Session ID Managers" (necessary for delegation) with "getZopeSessionID" a singleton? As I understand it, the "singleton" property prevents any child to reimplement the method. I must be wrong with this assumption. I probably misused the term "singleton". Thanks! -C ___ 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] Membership and PTK
Don't do man. Quick everybody, let's start a rescue comittee! Congrats Bill Phil - Original Message - From: "Bill Anderson" [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Saturday, September 30, 2000 6:40 PM Subject: [Zope-dev] Membership and PTK I am getting married Monday, and may be off lists for a week, so for anyone who has done _any_ Membership/PTK Integration, PLEASE, send it to me now, so I can work on it over the weekend, and next week. I don't want to duplicate work already done. Bill -- E PLURIBUS LINUX ___ 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] CoreSessionTracking proposal
DISCLAIMER: everything I'm about to say is my understanding based on my discussions with Chris about how to do session management, and does not necessarily reflect the current state of the session management code that he is developing, or what will end up in the Zope core. :) At 09:27 PM 9/30/00 +0200, Dieter Maurer wrote: I am very concerned about the "long living browser id". * Why should a browser id live longer than the session data maintained for the browser? It doesn't need to, necessarily. However, since the session data is decoupled from ID management, the browser ID needs to live at least as long as the longest type of session handled by the site. This means, if the session lifetime is in the order of an hour, the cookie need not live longer than, say, a day. Correct. Of course, if the site *also* contains session objects that have a life on the order of a day, then at least one cookie set by the site must have that longer lifetime. Thus, by setting the browser ID lifetime to at least as long as the longest session, one avoids having multiple cookies, one per session manager. * I am *VERY* suspicious whenever I get a cookie with an expiration date more than a few days in the future. If Zope tries to implement long living browser ids, I fear, Zope sites will have a high chance, I will no longer visit them. The actual lifetime of a browser ID will be controllable by the Zope site manager. I agree with you, however, in that the default lifetime should be reasonable. Indeed, I would suggest that the default simply be to use cookies with no expiration date, and which therefore only live so long as the user's browser is open, be it minutes or days. * I do not think "Annonymous" should have "Access Session Data" permission with the exception to its own session data. As I understand it, the "Access Session Data" permission gives you the right to call a method that returns you the session data for the current request, but does not give you the right to access arbitrary session data. Thus, one only has permission to see one's own session data. Again, session handling should be transparent, implemented by a mechanism that implements its own special purpose access policy (access to session data only by the session owner). No such policy is necessary, since access to the session data objects themselves is gated. You can't get to the session object unless you have management rights on the session data manager itself, or if the session data object is for "your" session -- the session for the current REQUEST. Once you have retrieved that session data object, what you can do with it is entirely dependent on what the object is. For example, a shopping cart object might grant Anonymous users access to place or remove items in it. Other types of session data objects might grant permissions to record click-tracking data, but not to view it. Nonetheless, most of these permissions issues are moot under normal circumstances, unless you are granting anonymous users the ability to create DTML or other executable methods in your site. Session data objects are not directly accessible through the web under normal circumstances without management access to the session data manager object. ___ 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] mailing list 'noise'
On Fri, 29 Sep 2000 10:23:52 +0200, Rik Hoekstra [EMAIL PROTECTED] wrote: Karl Anderson wrote: Ken Manheimer [EMAIL PROTECTED] writes: I dont see this as a problem: You only create a new list when the traffic for that proposal gets too great for zope-dev. Threading is good enough before that point. Yes, but zope-dev has a relatively high traffic load... Why should you have to put up with all that 'noise' if you're only interested in posts for your comparatively small discussion? I read the 2-10 articles that I'm probably interested in, and miss the 95% which is almost always noise. The question is why you'd want to receive all this if you don't have to (as remarked above). ...because it is usually a mistake to categorize any discussion as small, to exclude it from the mainstream zope-dev. I started this thread with a request that developers use zope-dev in the way requested by the Fishbowl Process document - but (I assume) it has also been valuable to people thinking about a next-generation wiki. That would not have happened if discussion was partitioned into Wikis (Todays wikis - not VaporWikiNG) unless some WikiNgWiki person was (by coincidence) keeping up with the FishbowlWiki. Are you really advocating that? as long as you can follow it. But for prolonged and diverging discussions? Not quite IMO/Experience. Can you explain why? Or for discussions that you fall into in the middle? Agreed - Todays Wikis are better than todays email list archives. And what if you want to follow discussions at different places, with different tools and you depend on a POP Server or differential access (POP/IMAP/Web) to a mailserver? Its true that the web model is increasingly becoming a lowest common denominator. Are your suggesting that a majority of Zope developers actually need that? (Agreed, a VaporWikiNG that does both would be nice) As I understood it, the discussion is less about tools and more about modes of discussion. But we couldnt be having this discussion (in any mode) without tools. *My* email and news tools support the mode of discussion that we are advocating *better* than *Todays* Wikis Toby Dickenson [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] CoreSessionTracking proposal
"Phillip J. Eby" wrote: Thus, by setting the browser ID lifetime to at least as long as the longest session, one avoids having multiple cookies, one per session manager. This is a good point and one that I probably didn't make clear in the use cases.. it's entirely possible to have a site with hundreds of session data managers. Each session data manager may implement its own policy as regards session data object expiry the type of session data object(s) it returns, as well as the storage of these session data objects. The point of the "browser id manager" is to handle the requirement to identify visitors between requests on behalf of all the session data managers in the system, as opposed to requiring each data manager to handle this identification. Thus, only one identifer need be used for all the session data managers in a system. However, as prompted by a Digital Creations "jam session", there are going to be changes to the use cases which actually make the "Browser Id Manager" into a "Session Id Manager" which will generate a "session token" that will carry both a "browser id" (meant to semipermanent) *and* a "session key" (meant to exist for the duration of a "session" as bounded by a "global" timeout period). This is purely an implementation detail, driven by the somewhat specious requirement that we allow people to associate a "session" bounded by one session data manager with a "session" bounded by another in the same system. (The implementation is also driven by my reluctance to store session key state related to a browserid inside Zope itself... it could be handled internally, but I've decided to put the "session" state on the client instead, it's easier). This will be an opt-in feature for session data manager implementations, and does not change much of the underlying principle of having a potentially "semipermanent" browser id. Contributed session data managers will be free to ignore the (oft-changing) session key component of the session token, and will be free to implement their own session expiry policies related only to the browser id component of the session token. However, it also means that session tokens (which replace browser ids as a identification value) will be prone to change much more frequently, as a new session token will be constructed every time the "global" session timeout expires, and it will contain both the "browser key" (potentially recycled out of a received token) and a new "session key". This may actually be beneficial (in some twisted, baroque way :-), because it means that people will be less tempted to set the cookie expiry time far into the future, as the cookie will be reset more often. * I am *VERY* suspicious whenever I get a cookie with an expiration date more than a few days in the future. If Zope tries to implement long living browser ids, I fear, Zope sites will have a high chance, I will no longer visit them. The actual lifetime of a browser ID will be controllable by the Zope site manager. I agree with you, however, in that the default lifetime should be reasonable. Indeed, I would suggest that the default simply be to use cookies with no expiration date, and which therefore only live so long as the user's browser is open, be it minutes or days. This sounds like a reasonable default. * I do not think "Annonymous" should have "Access Session Data" permission with the exception to its own session data. As I understand it, the "Access Session Data" permission gives you the right to call a method that returns you the session data for the current request, but does not give you the right to access arbitrary session data. Thus, one only has permission to see one's own session data. This is true. If you can guess (or steal) someone else's session token, however, you will be able to access the site "as that user", though you still will not be able to arbitrarily view session data object contents, only what is shown by the application code. I think Dieter's comments point out that the overarching requirement that sessioning be useful in the context of anonymity is at odds with the desire to lock down access to the data referenced by a session identifier. I will need to spell out very clearly in the user docs that session data not be used to store intensely sensitive information. -- Chris McDonough Digital Creations, Publishers of Zope http://www.zope.org ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] CORBA-ZODB: Is replacing global get_transaction() the only way...
Hi all, I am about to embark on integrating ZODB with CORBA, and am in the deep thinking phase of the endeavor. ;-) What I want to do is _explicitly_ manage connections and transactions without being able to depend on what thread is running. I know that this is _not_ the way that Zope works, but if I want to use standard CORBA I think I have only two choices: 1) Explicitly associate Connections with Transactions in my CORBA layer. What I need to do is allow any thread to change a Persistent object from some Connection, and make sure that the right transaction is called for "register". 2) Build a complete wrapping adapter layer that does thread synchronization to the actual Persistent objects and proper thread for the transaction. - Lots of overhead and redundant coding - tricks with ExtensionClass might make this adaptation simpler to code, but still it won't be easy. Obviously number one is my preferred choice. In order to accomplish that, I see only two ways: 1) Modify ZODB to maintain a Connection to Transaction link, and modify cPersistence.c to use that link in the changed() function instead of relying on the standard get_transaction() thread index. 2) Replace the get_transaction() in globals to return the appropriate Transaction regardless of thread. Again, my preference is number one. After going over the ZODB code, I _think_ that a Connection is always associated with one Transaction. If this assumption is true, then it should be safe to make the change I'm proposing. If not, then I need to understand why so that I can rethink how to solve my problem. ;-) I hope that I've made my problems and ideas for solutions clear, if not please let me know. Also, I think that I should be able to make the changes to ZODB myself within the next few week, but only if there is the _possibility_ of folding them back into the main Zope codebase. Thanks for any help, John D. Heintz CORBA Threading description: CORBA defines the POA, which has two standard threading policies: ORB Controlled Model Single Threaded Model The POA is basically a controller for requests to one or more distributed objects, with thread policy as one of its parameters. The first threading policy means whatever the ORB gives you - single or multi, and you have to deal with all synchronizations. The second I consider a mis-nomer because there can be many threads, but only one at a time will access objects for a given POA. (This is the model that I perceive being used by default for ZODB object from a specific Connection.) -- John D. Heintz DataChannel, Inc. Senior Engineer 512-633-1198 [EMAIL PROTECTED] Get your own FREE, personal Netscape WebMail account today at http://home.netscape.com/webmail ___ 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 )
