Re: [Zope-dev] A modest proposal: Replace medusa with Twisted
kapil thangavelu wrote: twisted is GPL and zope is not gpl compatible and that does not appear to be changing despite some mention from zc about trying to achieve compatiblity. Twisted is LGPL, and it might be possible to license it under something that will work with ZPL. I don't think this will be an issue if it comes to it. ___ 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] ZSQL methods lookup vars in REQUEST only (why?)
Hi Tim, Just to play devil's advocate; It seems this way, that methods pulling non-specifically from namespace could allow ways to modify the result if someone paid close attention to whats going on... i.e The total price of your shopping cart before its sent to the transaction broker. It requires the programmer to keep even more close care that all variables generated at runtime are first cleaned and wiped so that this same REQUEST couldn't just be anticipated by someone who's interested. Or can you suggest a way around this? Thanks, Paul Zwarts -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Tim McLaughlin Sent: Thursday, October 11, 2001 1:30 PM To: [EMAIL PROTECTED] Cc: Micah Martin Subject: [Zope-dev] ZSQL methods lookup vars in REQUEST only (why?) I've been asked too many times now by developers what is wrong when they call ZSQL Methods without passing parameters because their parameters are in the namespace. This seems to make sense to all new Zopers (and some older ones like myself) because all other DTML lookups are in the entire namespace. Anyway, I propose that ZSQLMethods change and do variable lookups in the entire namespace, not just the REQUEST object. It seems to be a simple enough change (at least it looks it) and I can submit the patches, but the harder thing is to get people to agree that it is a change for the better. The only argument that I have heard against it is that variables will be found mysteriously through the stack and that this is harder to understand. However, that just makes it inconsistent with all other DTML and therefore mysterious in its own way. Consistency is much better for learning and for remembering, and DTML in ZSQL should work the same as DTML in DTML Methods, etc. Please consider this and abuse me as appropriate ;) Regards, Tim -- Tim McLaughlin iterationZERO - www.iterationzero.com 703.481.2233 ___ 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] ZSQL methods lookup vars in REQUEST only (why?)
I agree. However, this is true of all DTML. I mean, its just as true in DTML methods that might REQUEST.set the args to the ZSQLMethod. ie. they could be tricked into REQUEST.set(ing) a false total etc. because they lookup all of their variables in the namespace. Cheers, Tim Paul Zwarts wrote: Hi Tim, Just to play devil's advocate; It seems this way, that methods pulling non-specifically from namespace could allow ways to modify the result if someone paid close attention to whats going on... i.e The total price of your shopping cart before its sent to the transaction broker. It requires the programmer to keep even more close care that all variables generated at runtime are first cleaned and wiped so that this same REQUEST couldn't just be anticipated by someone who's interested. Or can you suggest a way around this? Thanks, Paul Zwarts -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Tim McLaughlin Sent: Thursday, October 11, 2001 1:30 PM To: [EMAIL PROTECTED] Cc: Micah Martin Subject: [Zope-dev] ZSQL methods lookup vars in REQUEST only (why?) I've been asked too many times now by developers what is wrong when they call ZSQL Methods without passing parameters because their parameters are in the namespace. This seems to make sense to all new Zopers (and some older ones like myself) because all other DTML lookups are in the entire namespace. Anyway, I propose that ZSQLMethods change and do variable lookups in the entire namespace, not just the REQUEST object. It seems to be a simple enough change (at least it looks it) and I can submit the patches, but the harder thing is to get people to agree that it is a change for the better. The only argument that I have heard against it is that variables will be found mysteriously through the stack and that this is harder to understand. However, that just makes it inconsistent with all other DTML and therefore mysterious in its own way. Consistency is much better for learning and for remembering, and DTML in ZSQL should work the same as DTML in DTML Methods, etc. Please consider this and abuse me as appropriate ;) Regards, Tim -- Tim McLaughlin iterationZERO - www.iterationzero.com 703.481.2233 ___ 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 ) -- Tim McLaughlin iterationZERO - www.iterationzero.com 703.481.2233 ___ 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: Component Architecture / A modest proposal: Replace medusa with Twisted
Hi all I don't know if you're all familiar with this already, but reading about Twisted didn't immediately bring to mind Medusa, but rather certain aspects (specifically, *aspects*) of TransWarp, and of the Component Architecture (interfaces). I'm including a bite from http://twistedmatrix.com/page.epy/twistedphil.html Interesting? Regards, Jean Adverb Oriented Twisted is adverb oriented, which takes this one step further. Using inheritance and a simple naming convention, Twisted classes indicate what sort of events they are responding to. This allows for conveniently extensible protocols along defined vectors for extension. Let's say you wanted an object to be both a Twisted Reality player, and also an object accessible through Twisted PerspectiveBroker. You could define a class that looked like the following:: class RemotePlayer(reality.player.Player, spread.pb.Referenced): def ability_kill(self, sentence): #kills another player foo() def remote_killPlayer(self): #remote callable method. bar() Reality objects can have abilities, which you define by making a method prefixed with ability_. pb objects have remotely callable methods, which you define by making methods that begin with remote_; so this is effectively the same as a class, a snippet from the configuration file for a multi-user dungeon, and a remote interface definition file; the three of which are normally defined in different languages. Using adverb orientation and some simple python features, we can avoid the need for macros or complex parsing to achieve this effect. ___ 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] CVS: Zope-2_4-branch HelpSys b0rken.
- Original Message - From: Anthony Baxter [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, October 11, 2001 03:52 Subject: [Zope-dev] CVS: Zope-2_4-branch HelpSys b0rken. Someone's busted the help system recently. On a system running the current Zope-2_4-branch, I get: For the URL http://ekit-host.ekorp.com:8880/HelpSys/menu This URL is not reachable No error message. Error type: TypeError Error value: Catalog addIndex now requires the index type to be resolved prior to adding; create the proper index in the caller. Traceback follows: Traceback (innermost last): File /app/zope/ekit_code/lib/python/ZPublisher/Publish.py, line 122, in publish File /app/zope/ekit_code/lib/python/ZPublisher/mapply.py, line 104, in mapply (Object: menu) File /app/zope/ekit_code/lib/python/ZPublisher/Publish.py, line 111, in call_object (Object: menu) File /app/zope/ekit_code/lib/python/Shared/DC/Scripts/Bindings.py, line 322, in __call__ (Object: menu) File /app/zope/ekit_code/lib/python/Shared/DC/Scripts/Bindings.py, line 342, in _bindAndExec (Object: menu) File /app/zope/ekit_code/lib/python/App/special_dtml.py, line 182, in _exec (Object: menu) File /app/zope/ekit_code/lib/python/TreeDisplay/TreeTag.py, line 163, in render (Object: a tree tag) File /app/zope/ekit_code/lib/python/TreeDisplay/TreeTag.py, line 179, in tpRender (Object: HelpSys) File /app/zope/ekit_code/lib/python/TreeDisplay/TreeTag.py, line 306, in tpRenderTABLE (Object: HelpSys) File /app/zope/ekit_code/lib/python/HelpSys/HelpSys.py, line 190, in tpValues (Object: HelpSys) File /app/zope/ekit_code/lib/python/HelpSys/HelpSys.py, line 120, in helpValues (Object: HelpSys) File /app/zope/ekit_code/lib/python/App/Product.py, line 355, in getProductHelp (Object: PluginIndexes) File /app/zope/ekit_code/lib/python/HelpSys/HelpSys.py, line 278, in __init__ (Object: Help) File /app/zope/ekit_code/lib/python/Products/ZCatalog/ZCatalog.py, line 237, in __init__ (Object: catalog) File /app/zope/ekit_code/lib/python/Products/ZCatalog/Catalog.py, line 322, in addIndex TypeError: Catalog addIndex now requires the index type to be resolved prior to adding; create the proper index in the caller. I can't reproduce this problem with a fresh 2.4 checkout. Maybe they are running some 2.4 alpha oder beta version. This functionality in the released Zope 2.4 versions is working. Andreas - -Andreas Jung Zope Corporation- - EMail: [EMAIL PROTECTED]http://www.zope.com - - Python Powered http://www.python.org - - Makers of Zope http://www.zope.org - -Endings are just Beginnings - - ___ 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] ZSQL methods lookup vars in REQUEST only (why?)
Anyway, I propose that ZSQLMethods change and do variable lookups in the entire namespace, not just the REQUEST object. It seems to be a simple enough change (at least it looks it) and I can submit the patches, but the harder thing is to get people to agree that it is a change for the better. Paul Zwarts wrote: Just to play devil's advocate; It seems this way, that methods pulling non-specifically from namespace could allow ways to modify the result if someone paid close attention to whats going on... Exactly right. Even the guys at Zope.com dont pay close enough attention... Historically this has been the source of several security holes. Tim wrote: I agree. However, this is true of all DTML. That is true, and is the reason why dtml is inappropriate for any use except trivial document templating. In other uses it is either buggy (for the reason Paul mentioned) or very very ugly (because the author knows about the potential bugs, and in dtml it is cumbersome to work round them). It is a pity that the current zope-newbie documentation presents dtml as more than it is; as an essential part of the zope way. Anyway, there are plenty of alternatives to those non-trivial uses of dtml; Python Scripts, python products, CMF skins, etc. None of them are quite as slick, but at least they work. I dont know of a good alternative to SQLMethods, so I would prefer that they not be 'broken' in order to maintain consistency with a feature that many people recommend you should avoid. Tim also wrote: The only argument that I have heard against it is that variables will be found mysteriously through the stack and that this is harder to understand. However, that just makes it inconsistent with all other DTML and therefore mysterious in its own way. You are right that the mechanism for calling SQLMethods from DTML is different to calling DTML from DTML, but the odd one out is DTML calling DTML! DTML calling a SQLMethod current behaves the same as DTML calling PythonScript, pure python functions, extension class functions, or an external method. 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] CVS: Zope-2_4-branch HelpSys b0rken.
For the URL http://ekit-host.ekorp.com:8880/HelpSys/menu This URL is not reachable Yes, that's right. It's an internal system. I can't reproduce this problem with a fresh 2.4 checkout. Maybe they are running some 2.4 alpha oder beta version. This functionality in the released Zope 2.4 versions is working. I'm running CVS: Zope-2_4-branch, as the subject states. As of today. I'm mentioning this so that if there _is_ a problem in the current CVS (there's been a number of CVS commits related to catalog on that branch lately) it can be fixed before the next 2.4 release. -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ 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] Import I/O error
I've exported a folder from a 2.3.0 Zope installation and am trying to import the reulting myfile.zexp into a 2.4.1 installation on a different machine. This causes an IOError as documented below. The problem seems to have something to do with changing the ownership. Choosing 'Take ownership of imported objects' before clicking the Import button causes the IOError immediately. Choosing 'Retain existing ownership information' results in an apparently successful import, but when I click the imported Folder in the Zope management interface, the same IOError results. In other words, the folder gets imported, but I cannot view it, even if I'm logged in as root. Any idea what's wrong? Does it have something to do with the differing versions on the two machines? Joe Error Type: IOError Error Value: [Errno 5] Input/output error snip... [] Traceback (innermost last): File /usr/local/Zope-2.4.1-linux2-x86/lib/python/ZPublisher/Publish.py, line 223, in publish_module File /usr/local/Zope-2.4.1-linux2-x86/lib/python/ZPublisher/Publish.py, line 187, in publish File /usr/local/Zope-2.4.1-linux2-x86/lib/python/Zope/__init__.py, line 226, in zpublisher_exception_hook (Object: ApplicationDefaultPermissions) File /usr/local/Zope-2.4.1-linux2-x86/lib/python/ZPublisher/Publish.py, line 171, in publish File /usr/local/Zope-2.4.1-linux2-x86/lib/python/ZPublisher/mapply.py, line 160, in mapply (Object: manage_importObject) File /usr/local/Zope-2.4.1-linux2-x86/lib/python/ZPublisher/Publish.py, line 112, in call_object (Object: manage_importObject) File /usr/local/Zope-2.4.1-linux2-x86/lib/python/OFS/ObjectManager.py, line 591, in manage_importObject (Object: ApplicationDefaultPermissions) File /usr/local/Zope-2.4.1-linux2-x86/lib/python/OFS/ObjectManager.py, line 313, in _setObject (Object: ApplicationDefaultPermissions) File /usr/local/Zope-2.4.1-linux2-x86/lib/python/AccessControl/Owned.py, line 286, in manage_fixupOwnershipAfterAdd File /usr/local/Zope-2.4.1-linux2-x86/lib/python/AccessControl/Owned.py, line 187, in changeOwnership File /usr/local/Zope-2.4.1-linux2-x86/lib/python/ZODB/Connection.py, line 566, in setstate File /usr/local/Zope-2.4.1-linux2-x86/lib/python/zLOG.py, line 213, in LOG File /usr/local/Zope-2.4.1-linux2-x86/lib/python/ZLogger/ZLogger.py, line 17, in log_write File /usr/local/Zope-2.4.1-linux2-x86/lib/python/ZLogger/stupidFileLogger.py, line 99, in __call__ File /usr/local/Zope-2.4.1-linux2-x86/lib/python/ZLogger/stupidFileLogger.py, line 151, in stupid_log_write IOError: (see above) ___ 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] RE: Component Architecture / A modest proposal: Replace medusa with Twisted
At 01:52 PM 10/11/01 +0200, Jean Jordaan wrote: Hi all I don't know if you're all familiar with this already, but reading about Twisted didn't immediately bring to mind Medusa, but rather certain aspects (specifically, *aspects*) of TransWarp, and of the Component Architecture (interfaces). I'm including a bite from http://twistedmatrix.com/page.epy/twistedphil.html Interesting? What they're doing is more of a design pattern ala JavaBeans to create interface definitions using method signatures which can be recognized using introspection. However, a major point of the Component architecture is to get *away* from this style of doing things in Zope, because it makes it harder to use objects off the shelf, as one is required to code objects from the ground up for Zope use. Whereas, in the New Religion, you can just stick an __implements__ attribute on them, and set up some adapters. (Also, what Twisted is doing is entirely orthogonal to what TransWarp does, but I covered that in my reply to your post on the TransWarp mailing list. :) ) ___ 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] Component model, webservices and xmlrpc?
I just had to let someone access some RDBS data easily. Its already used in zope so I figured the easiest way was xmlrpc to the SQLMethod. Of course it wasn't that simple since sqlmethods return results set classes which are not marshalable via xmlrpc. In the end I had to write a python script wrapper around the sql method to turn it into a dictionary and replace all the Missing objects to blank strings. My question is, in the brave new world of the component model etc would such a scenario this be simpler? and how? I sure hope so :) I myself can see two ways out: - have a better webservice framework that lets you return objects rather than structures (more like com). I'm not sure if this what SOAP does or not. It seems a big ask since essentially the state would need to be kept on server side and proxy objects would need to connect back to that state for some untermined period of time. Potentially ugly but I can see it being very powerful. SOAP is structure-oriented (there are no object references), but this can still be very powerful if the system is well architected. - Have the ability to turn abitary classes into mashallable data. In this case the results class could support an results interface. There would be an adapter that knew how to turn objects implementing the results interface into xmlrpc marshallable data. Such adapters would be made for most standard objects? Am I right in saying the zope roadmap will make both of these possible in the not too distant future? The component model should be able to accomodate that case. You'd essentially be implementing a custom xml-rpc presentation of the object. Your custom implementation would handle the marshalling to the xmlrpc stream. Alternatively, the web services framework should provide a an alternative way to achieve the goal. Using (SOAP) web services, you could implement a web service that probably calls the existing sqlmethod and returns the results. The WS framework will be able to marshal many objects automatically based on an xml schema. That means that you would basically define a WSDL document that includes the schema and the marshalling would be done for you. Note that there is a little hand-waving here - I have some proofs of concept, but not as many hard details to give you as I'd like. Hope this helps though. Brian Lloyd[EMAIL PROTECTED] Software Engineer 540.361.1716 Zope Corporation http://www.zope.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 )
RE: [Zope-dev] ZSQL methods lookup vars in REQUEST only (why?)
I figured that I could be relatively safe by using heavy sessioning. First I started with SQLSession, and now CST... Tips I do: 1) Create all formbased applications by folders. In otherwords /folder/Support is actually the folder and you always put the root logic into index_html 2) The index_html is the control base, that will call in methods which are your forms. (This way crawlers see a directory with only 1 page (methods are hidden AFAIK)) I always split the application into a minimum of 4 pieces (index_html, form, validation form, output). For multi-stage forms like a shop, the number is sitting around 10. 3) Split all forms OUT into theses methods, but DON'T put the form tags in that method. Keep them in the index_html so you cannot go directly to a single page other than index_html and be able to submit. It basically fragments everything to be unuseable by itself. 4) I use CoreSessionTracking VERY heavily. Using a skin based concept, every pageload executes a sessionlogic method, which does switching. For instance, when any kind of form is submitted, I set a sessionvariable called ACTION to a value like 'check'. Then the index_html is sensitive to this change, and will process the form ONLY if the form was submitted through the whole process properly. I also use this validation technique to check forms and feedback incompletenesss. If youre carefull, the session variables cannot be modified outside of the process flow so you ensure nothing funky is going on. 5) For things like my shop, prices are always checked and modified in the ZSQL method itself. In other words, I use dtml inside the ZSQL method to enforce cascade SQL calls. Like when a customer requests the price of a product and decides to buy it, the price is stored in hidden fields on the html page, but it doesn't make a differene, becausse at runtime, the ZSQL ethod does a second redundant retrieve when adding the record, so the price value ALWAYS is what it should be and cant be changed by any hack (short mucking with the code) Its totally obvious the pure python would be good instead, but I'm not very good at it yet, and can crank out dmtl much faster. Just some tips if anyone's interested... Paul Zwarts -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Toby Dickenson Sent: Thursday, October 11, 2001 2:43 PM To: [EMAIL PROTECTED] Cc: Paul Zwarts; [EMAIL PROTECTED] Subject: Re: [Zope-dev] ZSQL methods lookup vars in REQUEST only (why?) Anyway, I propose that ZSQLMethods change and do variable lookups in the entire namespace, not just the REQUEST object. It seems to be a simple enough change (at least it looks it) and I can submit the patches, but the harder thing is to get people to agree that it is a change for the better. Paul Zwarts wrote: Just to play devil's advocate; It seems this way, that methods pulling non-specifically from namespace could allow ways to modify the result if someone paid close attention to whats going on... Exactly right. Even the guys at Zope.com dont pay close enough attention... Historically this has been the source of several security holes. Tim wrote: I agree. However, this is true of all DTML. That is true, and is the reason why dtml is inappropriate for any use except trivial document templating. In other uses it is either buggy (for the reason Paul mentioned) or very very ugly (because the author knows about the potential bugs, and in dtml it is cumbersome to work round them). It is a pity that the current zope-newbie documentation presents dtml as more than it is; as an essential part of the zope way. Anyway, there are plenty of alternatives to those non-trivial uses of dtml; Python Scripts, python products, CMF skins, etc. None of them are quite as slick, but at least they work. I dont know of a good alternative to SQLMethods, so I would prefer that they not be 'broken' in order to maintain consistency with a feature that many people recommend you should avoid. Tim also wrote: The only argument that I have heard against it is that variables will be found mysteriously through the stack and that this is harder to understand. However, that just makes it inconsistent with all other DTML and therefore mysterious in its own way. You are right that the mechanism for calling SQLMethods from DTML is different to calling DTML from DTML, but the odd one out is DTML calling DTML! DTML calling a SQLMethod current behaves the same as DTML calling PythonScript, pure python functions, extension class functions, or an external method. 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 ) ___ Zope-Dev maillist -
Re: [Zope-dev] A modest proposal: Replace medusa with Twisted
There is another approach however for getting Java and Zope together A few weeks back I was mucking around with the Python Java Extension (see Python 9 proceedings) and was able to interact with Java classes/instances directly from Zope by calling ExternalMethods. PJE basically allows the Java vm to be loaded into the python interpreter. Tim I can speak about this one... The difficult part of getting Zope to w ork on Java, IMHO, is not the server. Without too terribly much work, I think you could get a servlet in front of Zope (once you've taken care of all of the other things). We've made some progress toward getting Zope running on Java (http://www.phabric.org). The past few weeks, phabric has been on the back burner at Web Elite because of unrelated paying work. There are two main areas of work in getting Zope on top of Java: the C modules and differences between C Python and Jython. We've made quite a bit of progress in both of those areas, but there's still more to be done before Zope will fire up and answer a request. Kevin Tim Hoffman Zute Pty Ltd mobile: 0411 06 fax:+61 8 6210 1883 email: [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] A modest proposal: Replace medusa with Twisted
Been there, done that. JPE (as it was originally known, Java Python Extensions), has a fatal flaw, at most one JVM can be attached to a Python script at any one time, this single instance attaches itself to a single thread, and is not available in any other thread. I've had this working with Zope, even serving pages with Java stuff creating the content, but only intermittently. When Zope serves from the thread with the JVM attached everything is great, as soon as the thread changes, all hell breaks loose. That said, I think JPE/PJE is the best way forward, but this problem needs to be solved (if it hasn't already). Phil - Original Message - From: Tim Hoffman [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, October 11, 2001 4:32 PM Subject: Re: [Zope-dev] A modest proposal: Replace medusa with Twisted There is another approach however for getting Java and Zope together A few weeks back I was mucking around with the Python Java Extension (see Python 9 proceedings) and was able to interact with Java classes/instances directly from Zope by calling ExternalMethods. PJE basically allows the Java vm to be loaded into the python interpreter. Tim I can speak about this one... The difficult part of getting Zope to w ork on Java, IMHO, is not the server. Without too terribly much work, I think you could get a servlet in front of Zope (once you've taken care of all of the other things). We've made some progress toward getting Zope running on Java (http://www.phabric.org). The past few weeks, phabric has been on the back burner at Web Elite because of unrelated paying work. There are two main areas of work in getting Zope on top of Java: the C modules and differences between C Python and Jython. We've made quite a bit of progress in both of those areas, but there's still more to be done before Zope will fire up and answer a request. Kevin Tim Hoffman Zute Pty Ltd mobile: 0411 06 fax:+61 8 6210 1883 email: [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 ) ___ 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] A modest proposal: Replace medusa with Twisted
Phil Harris wrote: That said, I think JPE/PJE is the best way forward, but this problem needs to be solved (if it hasn't already). Latest CVS README says: Multithreading == Multithreading issues are taken care of. There is still a known issues concerning process termination (non-deamonic thread hang out) that can require that the process be interrupted or killed explicitely. Some more work need to be done on process termination and cleanup conditions of the virtual machines. ___ 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] GUF and SQL
On Thu, 11 Oct 2001, Andre Schubert wrote: I'am using GUF with ZSqlMethods and found out, that every time a object is accessed the sql-method is called, [...] Is there a why to implement such a AUTHENTICATION-String cache in the GUF-Product, it brings a lot of performance, when using GUF with SQL. Did you try using the caching built in to sql methods? Granted that doesn't address 100% of the issue, but it might address high-90s% of it. --RDM ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] A modest proposal: Replace medusa with Twisted
On Thursday 11 October 2001 03:30 am, Itamar Shtull-Trauring wrote: kapil thangavelu wrote: twisted is GPL and zope is not gpl compatible and that does not appear to be changing despite some mention from zc about trying to achieve compatiblity. Twisted is LGPL, and it might be possible to license it under something that will work with ZPL. I don't think this will be an issue if it comes to it. itamar, thanks for the license clarification. i didn't mean to suggest that its not a good idea to work on it. i was hoping that someone from zc would give some sort of status update to paul's statements from http://aspn.activestate.com/ASPN/Mail/Message/622793 june. kapil ___ 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] A modest proposal: Replace medusa with Twisted
People waste much more time arguing about the GPL license, than it would take for them to completely rewrite the entire Python and Zope code base from scratch under the GPL. So if you can't live with a non-GPL license, then instead of arguing about it, get yourself to work rewriting a new system from scratch under GPL, so you'll get what you want a lot sooner, and not waste everyone else's time who's already been over this before. Please stop using the GPL as a weapon to distract and waste the time of non-GPL projects, and do something constructive instead. E-fuck'n-nough said. -Don ___ 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] ZPL2.0
Only a little bit more arm twisting needs to be done in order for RMS to approve ZPL 2.0 as GPL compatable. We're very close, it's just sometimes, tricky to get a straight answer when speaking in legal terms. and there was much rejoicing:) seriously, i'll buy a round for those involved who show up at ipc10. dealing with RMS is tricky period. kapil __ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.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] Zope on Apache (Zapache? Zopache?)
Michel Pelletier proposes an interesting idea, of integrating Zope with Apache 2.0. That sounds like a really great idea with many upsides -- especially because you could write all kinds of interesting Apache extensions in Python. Has anyone written that idea up, or discussed it on other mailing lists? As a first step, how about using SWIG to expose the Apache 2.0 api to mod_python. -Don From: [EMAIL PROTECTED] (Michel Pelletier) Date: Wed, 10 Oct 2001 11:09:45 -0400 Subject: [Zope-dev] A modest proposal: Replace medusa with Twisted Just to throw out another idea, Amos has discussed with me in the past the idea of replacing medusa with Apache 2.0. Compelling as many of Twisted's features may be, Apache 2.0 as far as i can tell supports many of them as well (except perhaps jython integration, which is a pipe dream anyway for Zope). Apache has the upshot in that it is rock solid, tested by millions, trusted by even more, and no doubt one of the most actively developed peices of software there is. For ZC the upshots of 1) not needing to maintain it, and 2) it being a excellent marketing tool outweight many technical benifits that twisted may have that Apache doesn't (I'd like to know what the differences are, however). For example, does twisted do URL rewriting? proxy? process/thread job control? Twisted does have the advantage of 1, but not 2. Further, our faith in the continuing development of Apache is, de facto, more than that of twisted simply based on the age, number of users, and number of developers of each project. I'm not dismissing the idea, I'm just pointing out an alternative to Itamar's alternative. ;) -Michel ___ 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] A modest proposal: Replace medusa with Twisted
Hmhm, that is cool, I'll take another look then :) - Original Message - From: Itamar Shtull-Trauring [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, October 11, 2001 5:39 PM Subject: Re: [Zope-dev] A modest proposal: Replace medusa with Twisted Phil Harris wrote: That said, I think JPE/PJE is the best way forward, but this problem needs to be solved (if it hasn't already). Latest CVS README says: Multithreading == Multithreading issues are taken care of. There is still a known issues concerning process termination (non-deamonic thread hang out) that can require that the process be interrupted or killed explicitely. Some more work need to be done on process termination and cleanup conditions of the virtual machines. ___ 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] HELP PLEASE
Hi all, i have serious problems with my zope. Last time he dies very often with error code 13,and since to today he slows down extremly. To view the Control_Panel/DebugForm it takes up to 1 minute and thats not acceptable. How can i track down these problems. I run Zope-2.2.4 on Immunix-RedHat 6.2 thanks a lot as ___ 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] HELP PLEASE
I had this once (the slowing down) when an other process was eating up all memory and zope was constantly paged out. Robert - Original Message - From: Andre Schubert [EMAIL PROTECTED] To: zope [EMAIL PROTECTED] Sent: Friday, October 12, 2001 6:49 AM Subject: [Zope-dev] HELP PLEASE Hi all, i have serious problems with my zope. Last time he dies very often with error code 13,and since to today he slows down extremly. To view the Control_Panel/DebugForm it takes up to 1 minute and thats not acceptable. How can i track down these problems. I run Zope-2.2.4 on Immunix-RedHat 6.2 thanks a lot as ___ 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 )
