[Zope-dev] Poor programming practice?
I have been trying to make use of the builtin medusa ftp_server classes and after struggling a while came across the strange practice some internal zope developer has of dynamically changing classes at runtime. ie in ZServer.FTPServer I came across from medusa.ftp_server import ftp_channel, ftp_server, recv_channel ... ... # Override ftp server receive channel reponse mechanism # XXX hack alert, this should probably be redone in a more OO way. def handle_close (self): .. self.readable=lambda :0 # don't call close again recv_channel.handle_close=handle_close which makes it virtually impossible to re-use medusa's ftp_server in a reasonable way. The comment says it all. The real problem is that ftp_channel uses a method make_recv_channel which uses a global class recv_channel and the recv_channel class has a particular method which zope wants to override. How ought this kind of situation to be handled more cleanly? -- Robin Becker ___ 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] Poor programming practice?
Robin Becker wrote: The real problem is that ftp_channel uses a method make_recv_channel which uses a global class recv_channel and the recv_channel class has a particular method which zope wants to override. How ought this kind of situation to be handled more cleanly? I haven't looked at the code, so the following is based only on your paragraph above, and probably doesn't apply to the real classes we're talking about :-) This sounds like a classic application of the Factory Method pattern. In brief, you have the ftp_channel class. Its instances have a make_recv_channel method. This is the Factory Method. It returns whatever is appropriate for a recv_channel. You create a subclass derived fom ftp_channel called perhaps zope_ftp_channel, which defines a new make_recv_channel method. This new method does whatever Zope needs for making the recv_channel. The other option is to use the Abstract Factory pattern. In this case, you'd pass the constructor of the ftp_channel class a bound method (or a function) that returns the appropriate kind of recv_channel. You could let an ftp_channel instance know about this bound method (or function) by other means instead, rather than passing it in the constructor. Both patterns are discussed in the infamous "Gang Of Four book" Design Patterns: Elements of reusable object-oriented software, Gamma, Helm, Johnson and Vlissides. There will be explanations on the web somewhere too, no doubt. -- 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 )
[Zope-dev] Re: [Zope] Found an fatal error in Zope 2.3.0 :)
On Wed, Jan 31, 2001 at 12:59:55PM +0100, Radek Hnilica wrote: Hello all, While trying to debianize, compile and install new zope 2.3.0 I found that file z2.py doesn't contain necesary first line. I look to previous version 2.2.4 and there it is. #!/usr/bin/env python The source was taken from zope.org. I'v also look at CVS and there it's missing to. The line has been added by the maintainer of the Debian package of Zope, Gregor Hoffleit. The line was never there in Zope CVS. Zope binary and source distributions use a shell script called 'start' to run z2.py with the python interpreter. Read the documentation that comes with the source distribution. You can of course always add the line yourself. -- Martijn Pieters | Software Engineer mailto:[EMAIL PROTECTED] | Digital Creations http://www.digicool.com/ | Creators 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] REMINDER: Zope track at Python 9!
Hello all, Just a reminder that the ninth international Python conference is right around the corner, and that there will be a Zope track again this year. More information on the Zope Track at Python 9 may be found at: http://www.python9.org/p9-zope1.html We invite you to come out and meet fellow Zopistas, learn about Perl for Zope, the future of ZPatterns and what's in store for Zope in 2001. Note that "early bird" registration for Python 9 ends February 2nd - for more information about Python 9 or the Zope Track see http://www.python9.org/. Brian Lloyd[EMAIL PROTECTED] Software Engineer 540.371.6909 Digital Creations http://www.digicool.com ___ 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: [medusa] Re: [Zope-dev] asynchat producer ready() method patch.
On Wednesday 31 January 2001 04:18, Donovan Baarda wrote: On Mon, Jan 29, 2001 at 07:26:56PM +0100, Dieter Maurer wrote: Donovan Baarda writes: On Sun, Jan 28, 2001 at 09:31:07PM +0100, Dieter Maurer wrote: Donovan Baarda writes: I remember reading ages ago on a wishlist for ZServer that someone was thinking of adding blocking support to producers. This patch adds support for just that in a non-intrusive way. I haven't tried applying this patch to ZServer, but it _should_ work. What does "blocking support dor producers" mean? Disclaimer: you must be moderately familiar with ZServer/medusa/asynchat for the following to make sense; Asynchat used by ZServer and medusa use producers as a way to "push" data through an async interface. The current version of asynchat requires that producers be able to produce data immediately on calling their more() method, untill they are finished, when they return ''. My patch adds support for producers being able to "block" by letting asynchat know if they are ready via a ready() method. This allows you to use the simple producer model to push data that may not be immediately available. An example would be a http-fetch producer that fetches data from upstream for a proxy. This patch is only useful for people creating or modifying things like medusa or ZServer. Thank you for this good explanation. By now, I think, it would not be usefull for ZServer, at least not for standard operations. ZServer is a multi-threaded server, where different requests are serviced by different threads. The thread may block and does simply not return from "more()". On first thought, you patch might free some blocked threads to do productive work. However, Zope's transaction system is linked to thread management. If you patch would be used for that, Zope's transaction subsystem would need to be rewritten. Hmmm, it's been a while since I looked at ZServer, I might have to take another look. I thought that it pre-spawned a number of threads that each ran their own asyncore.loop event handler. I thought this was a neat way to get the benefits of async event handlers and distributing threads on multiple processors. Unless it spawns new threads when it needs them, it would still be possible for ZServer to get blocked if all the threads were blocked. disclaimer: insert here. zserver has a main thread which binds and listens, passing requests to a pool of zpublisher threads. the zpublisher threads communicate with the client via the main threads dispatcher, ie output is funneled back into the main thread's dispatcher so as not to tie up threads talking to distant clients. reference: Zserver/medusa/select_trigger.py python has a global interpreter lock, so multiple cpus have little utility. However, my patch is only useful if you _have_ producers that can block. It is usually possible to re-structure your system so that no producers block (typicaly by using a dispatcher instead of a producer). The ready() block feature is really a shortcut way of modifying an existing producer-based design when you realise that the producer can block; ie an alternative way of implementing it that may or may not be better. i've taken a quick look at the patch, i find it interesting in that it provides i think a way to implement a Proactor type server vs the standard medusa Reactor style server. reference: Patterns of System Architecture Vol II. Douglas Schmidt et al reference: http://www.cs.wustl.edu/~schmidt/PDF/proactor.pdf and a webserver that makes use of this pattern http://www.cs.wustl.edu/~jxh/research/ kapil In my case I wanted to create a cached-ftp-backend filesystem that medusa could serve via ftp or http. Unfortunately the existing ftp and http server implementations used producers to pull data from the abstract filesystem. Since my "filesystem" could block pretty severly, I either needed to completely re-write the http and ftp servers to use dispatchers instead of producers, or implement blocking for producers (or use a seperate thread for each request, but I thought that defeated the purpose of using an async event loop). I really must look at ZServer to figure out how it handles things... I suspect that my patch by itself would not _hurt_ ZServer, but perhaps if you started using the ready() feature it provides it might cause problems. I'll have a look at ZServer again soon and give you an evaluation of how my patch would interact with it. Who knows, someone might find a need for blocking producers as ZServer evolves, and if people know the patch exists, they might use it instead of re-structuring to get around it :-) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or
[Zope-dev] Fw: [Zope-dev] Storing session objects in a ZODB
This is a forwarding of an interesting session-related discussion between Andy and I... it covers the idea of storing session states as "snapshots" at a particular time, later allowing users to select a session state. This is useful if you wish to allow users to make incremental changes to data in a session and "bookmark" a session state for later copying into the current session. This is something that the "bare" session tracking stuff won't do for you, although it can facilitate it tremendously. Input welcomed! - C - Original Message - From: "Andy McKay" [EMAIL PROTECTED] To: "Chris McDonough" [EMAIL PROTECTED] Sent: Wednesday, January 31, 2001 1:56 PM Subject: Re: [Zope-dev] Storing session objects in a ZODB I think you may be trying to use sessions to do something that sessions don't do. You can *use* the sessioning machinery as a base to build the infrastructure to do such a thing, but it won't do it out of the box. I am currently trying to build an "onSessionStart" and "onSessionEnd" event into session data objects. If you had this capability, an arbitrary Python method (or DTML method or external method) could be called when a session data object is created and when it expires. If you were to make use of these hooks to copy the state of the session data object into another structure (related to the currently logged in user - a "checkpoint" if you will), you could build a catalog of session states that could be recopied into the current session namespace. Alternately, you could forego the use of events and just have a button that says "save session state" somewhere, and copy the contents of the session namespace into something else. Then when a user wanted to choose a session state, copy it back into the current session namespace. This is the same idea, it just lets the user be explicit about what session state he wants to use instead of depending on the event hook to create a new state. Bingo, yes that's it! Does this make sense? Can I cc this to Zope-Dev so we can get some discussion about it? Absolutely! -- Andy McKay. - Original Message - From: "Chris McDonough" [EMAIL PROTECTED] To: "Andy McKay" [EMAIL PROTECTED] Sent: Tuesday, January 30, 2001 9:53 AM Subject: Re: [Zope-dev] Storing session objects in a ZODB Andy, I'm still not sure why you wouldn't set up an external data container.. if you want, you can call me at 540-371-6909 if you think you can explain it better over the phone... - C - Original Message - From: "Andy McKay" [EMAIL PROTECTED] To: "Chris McDonough" [EMAIL PROTECTED] Sent: Tuesday, January 30, 2001 12:28 PM Subject: Re: [Zope-dev] Storing session objects in a ZODB Well each user rummages through a site and saves preferences, I use these preferences for displaying things in a certain manner, generating SQL etc. Since some of these SQL statements get quite complex, it would be nice to be to able to pull saved session x which has a query that "looks up by x by y excluding z" etc... So anyway I like using the ZODB for this kind of storage since it's of low volume and a large amount of reads and the users want to use acquisition to the full (we have a wacky hierarchy). If I could pull that into a text area to allow level editing then that would be an added bonus... Did that make sense? -- Andy McKay. - Original Message - From: "Chris McDonough" [EMAIL PROTECTED] To: "Andy McKay" [EMAIL PROTECTED] Sent: Monday, January 29, 2001 5:49 PM Subject: Re: [Zope-dev] Storing session objects in a ZODB Sure but users want to be able acess and manipulate the stored session objects, without them being loaded... Im going for a bike ride to think about this one. Erm. What? :-) Can you give me an example? ___ 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] Fw: [Zope-dev] Storing session objects in a ZODB
Well my quick hack and wacky of doing it is as follows: - I wrote a quick simple class "ZStore" that has as one of its properties a pickle, which you can read and write to using cStringIO - I make a ZStore object, throw in the session object, it pickles it as the data property, I add a few more useful properties, like title, owner etc... - To get it back I get that object, unpickle that property and I have the session back. Quick hack that works for me and allows me to change the content of a session object, without having to change the storage. Im sure someone will come up with a better solution. -- Andy McKay. - Original Message - From: "Chris McDonough" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, January 31, 2001 11:28 AM Subject: [Zope-dev] Fw: [Zope-dev] Storing session objects in a ZODB This is a forwarding of an interesting session-related discussion between Andy and I... it covers the idea of storing session states as "snapshots" at a particular time, later allowing users to select a session state. This is useful if you wish to allow users to make incremental changes to data in a session and "bookmark" a session state for later copying into the current session. This is something that the "bare" session tracking stuff won't do for you, although it can facilitate it tremendously. Input welcomed! - C - Original Message - From: "Andy McKay" [EMAIL PROTECTED] To: "Chris McDonough" [EMAIL PROTECTED] Sent: Wednesday, January 31, 2001 1:56 PM Subject: Re: [Zope-dev] Storing session objects in a ZODB I think you may be trying to use sessions to do something that sessions don't do. You can *use* the sessioning machinery as a base to build the infrastructure to do such a thing, but it won't do it out of the box. I am currently trying to build an "onSessionStart" and "onSessionEnd" event into session data objects. If you had this capability, an arbitrary Python method (or DTML method or external method) could be called when a session data object is created and when it expires. If you were to make use of these hooks to copy the state of the session data object into another structure (related to the currently logged in user - a "checkpoint" if you will), you could build a catalog of session states that could be recopied into the current session namespace. Alternately, you could forego the use of events and just have a button that says "save session state" somewhere, and copy the contents of the session namespace into something else. Then when a user wanted to choose a session state, copy it back into the current session namespace. This is the same idea, it just lets the user be explicit about what session state he wants to use instead of depending on the event hook to create a new state. Bingo, yes that's it! Does this make sense? Can I cc this to Zope-Dev so we can get some discussion about it? Absolutely! -- Andy McKay. - Original Message - From: "Chris McDonough" [EMAIL PROTECTED] To: "Andy McKay" [EMAIL PROTECTED] Sent: Tuesday, January 30, 2001 9:53 AM Subject: Re: [Zope-dev] Storing session objects in a ZODB Andy, I'm still not sure why you wouldn't set up an external data container.. if you want, you can call me at 540-371-6909 if you think you can explain it better over the phone... - C - Original Message - From: "Andy McKay" [EMAIL PROTECTED] To: "Chris McDonough" [EMAIL PROTECTED] Sent: Tuesday, January 30, 2001 12:28 PM Subject: Re: [Zope-dev] Storing session objects in a ZODB Well each user rummages through a site and saves preferences, I use these preferences for displaying things in a certain manner, generating SQL etc. Since some of these SQL statements get quite complex, it would be nice to be to able to pull saved session x which has a query that "looks up by x by y excluding z" etc... So anyway I like using the ZODB for this kind of storage since it's of low volume and a large amount of reads and the users want to use acquisition to the full (we have a wacky hierarchy). If I could pull that into a text area to allow level editing then that would be an added bonus... Did that make sense? -- Andy McKay. - Original Message - From: "Chris McDonough" [EMAIL PROTECTED] To: "Andy McKay" [EMAIL PROTECTED] Sent: Monday, January 29, 2001 5:49 PM Subject: Re: [Zope-dev] Storing session objects in a ZODB Sure but users want to be able acess and manipulate the stored session objects, without them being loaded... Im going for a bike ride to think about this one.
Re: [Zope-dev] Fw: [Zope-dev] Storing session objects in a ZODB
Cool! Note that the session data object implements the mapping interface, so you don't really need to pickle up a copy of it. I'd recommend against this, although it seems to be working well for you. Instead, to save a session state, I'd just grab the current session data object and iterate over its items, grabbing things out of it that are interesting to my application. Then I'd copy these things into another data structure, maybe by sticking them into an instance of a class that also implements the mapping interface and put that instance in a folder somewhere which is related to the currently logged-in user. Then when a user wanted to restore a saved session state, get a list of session state objects in his session state folder, present them to him, have him select one. When he does, copy the items out of it into the current session data object. The nice thing about this general strategy is that you can work with the current session data object in all of your app code that depends on session state. How the session state is saved and restored (and what the session data object values are) is completely independent of the app code. - Original Message - From: "Andy McKay" [EMAIL PROTECTED] To: "Chris McDonough" [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, January 31, 2001 2:47 PM Subject: Re: [Zope-dev] Fw: [Zope-dev] Storing session objects in a ZODB Well my quick hack and wacky of doing it is as follows: - I wrote a quick simple class "ZStore" that has as one of its properties a pickle, which you can read and write to using cStringIO - I make a ZStore object, throw in the session object, it pickles it as the data property, I add a few more useful properties, like title, owner etc... - To get it back I get that object, unpickle that property and I have the session back. Quick hack that works for me and allows me to change the content of a session object, without having to change the storage. Im sure someone will come up with a better solution. -- Andy McKay. - Original Message - From: "Chris McDonough" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, January 31, 2001 11:28 AM Subject: [Zope-dev] Fw: [Zope-dev] Storing session objects in a ZODB This is a forwarding of an interesting session-related discussion between Andy and I... it covers the idea of storing session states as "snapshots" at a particular time, later allowing users to select a session state. This is useful if you wish to allow users to make incremental changes to data in a session and "bookmark" a session state for later copying into the current session. This is something that the "bare" session tracking stuff won't do for you, although it can facilitate it tremendously. Input welcomed! - C - Original Message - From: "Andy McKay" [EMAIL PROTECTED] To: "Chris McDonough" [EMAIL PROTECTED] Sent: Wednesday, January 31, 2001 1:56 PM Subject: Re: [Zope-dev] Storing session objects in a ZODB I think you may be trying to use sessions to do something that sessions don't do. You can *use* the sessioning machinery as a base to build the infrastructure to do such a thing, but it won't do it out of the box. I am currently trying to build an "onSessionStart" and "onSessionEnd" event into session data objects. If you had this capability, an arbitrary Python method (or DTML method or external method) could be called when a session data object is created and when it expires. If you were to make use of these hooks to copy the state of the session data object into another structure (related to the currently logged in user - a "checkpoint" if you will), you could build a catalog of session states that could be recopied into the current session namespace. Alternately, you could forego the use of events and just have a button that says "save session state" somewhere, and copy the contents of the session namespace into something else. Then when a user wanted to choose a session state, copy it back into the current session namespace. This is the same idea, it just lets the user be explicit about what session state he wants to use instead of depending on the event hook to create a new state. Bingo, yes that's it! Does this make sense? Can I cc this to Zope-Dev so we can get some discussion about it? Absolutely! -- Andy McKay. - Original Message - From: "Chris McDonough" [EMAIL PROTECTED] To: "Andy McKay" [EMAIL PROTECTED] Sent: Tuesday, January 30, 2001 9:53 AM Subject: Re: [Zope-dev] Storing session objects in a ZODB Andy, I'm still not sure why you wouldn't set up an external data container.. if you want, you can call me at 540-371-6909 if you think you can explain it better over the phone... - C
Re: [Zope-dev] Fw: [Zope-dev] Storing session objects in a ZODB
Cool! Note that the session data object implements the mapping interface, so you don't really need to pickle up a copy of it. I'd recommend against this, although it seems to be working well for you. Any special reason why I shouldn't pickle apart from the fact that the ZODB will do it to save the object? Instead, to save a session state, I'd just grab the current session data object and iterate over its items, grabbing things out of it that are interesting to my application. Then I'd copy these things into another data structure, maybe by sticking them into an instance of a class that also implements the mapping interface and put that instance in a folder somewhere which is related to the currently logged-in user. Cool, I'll have to look at the mapping interface. I use a "fixed" version of UserInfoFolder to maintain a folderish object on each person, Im throwing this into there. Works nicely. Then when a user wanted to restore a saved session state, get a list of session state objects in his session state folder, present them to him, have him select one. When he does, copy the items out of it into the current session data object. The nice thing about this general strategy is that you can work with the current session data object in all of your app code that depends on session state. How the session state is saved and restored (and what the session data object values are) is completely independent of the app code. Yep this is what I like. Im actually thinking this simple ZStore class is a useful little object for throwing stuff into, if I get mapping working I'll release the whole 50 lines of code it currently is... Thanks for your help. -- Andy McKay. ___ 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] Fw: [Zope-dev] Storing session objects in a ZODB
Any special reason why I shouldn't pickle apart from the fact that the
ZODB
will do it to save the object?
The session data object class may move in the future, which in the "normal"
case would only require that you restart the server (if they're transient)
or flush your data container (if they're persistent). But if you've got
pickles of older session data objects hanging around (which point to a
no-longer-existing class), your app will likely break. Instead, it's better
to rely on a class that you have some control over. Using pickles of
session data objects, you're depending on an implementation detail that may
change. Additionally, I doubt it's the case in your implementation, but
unpickling arbitrary user-contributed data can be a serious security hole.
In broader terms, however, you already have a superpickler (the ZODB), you
might as well use it. ;-)
When I say mapping interface, I just mean that the session data object looks
like a dictionary. So:
mystorageobject = mycustomclassthatlookslikeadictionary()
data = sdm.getSessionData()
for k,v in data.items():
mystorageobject[k] = v
afolder._setObject('anid', mystorageobject)
Will do the right thing.
Yep this is what I like. Im actually thinking this simple ZStore class is
a
useful little object for throwing stuff into, if I get mapping working
I'll
release the whole 50 lines of code it currently is...
It would be really useful to have generalized support for something like
this.
___
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 )
