Log in
Forgot your password?
History for PerlForZope
??changed:- Perl For Zope What does Perl for Zope mean, both from a software perspective and a contract perspective? Message The message we are sending out is that Perl is now a scripting language for Zope. This does *not* mean that any of Zope will be rewritten in Perl, nor does it mean that Zope "products" (read: components) can be created in Perl. To a certain extent, existing Perl code can be integrated into Zope. Software The following is a discussion of software requirements. Each bullet is preceded with a number that rates the requirement ('1' is high, '3' is low). o (1) Concurrency. Stuff in Perl should be at least as concurrent as stuff in Python. o (1) [External Method]s. ExternalMethods in Zope are functions in a file on disk that are bound to an object in Zope (e.g. a Folder) as a method. Note -- these files on disk are often confused with modules. This mistake is reasonable and easy to make. Thus, a Perl external method would need to include the namespace of "self" from the object it is bound to. Python external methods work outside the security machinery. Note -- It isn't necessary to have new kinds of addable objects. It should be possible to simply add an external method and have it be a perl method by virtue of being in a perl module, identified by a '.pl' suffix. o (1) No memory leaks. o (1) Perl Methods. Our forthcoming Python Methods (PyM) have their code stored in the object database. Importantly, they obey the same security machinery used by the 'expr' in DTML. It is possible that PyM will have knobs for dialing up/down the security. Thus, Perl Methods (PerlM) will be stored in the object database and must obey the same security machinery. They are attached to folder or ZClass. o (1) The cache works, meaning methods in Perl can be activated/deactivated. PerlM or Perl EM objects can get deactivated by the cache manager. When the are re-activated, they are re-evaluated. o (1) Works with acquisition. All Perl methods should work with the concept of acquisition, where the attributes of parents in your path appear to be attributes of you. Jim -- This should fall out of having access to the "self" namespace. o (2) Perl methods attached to Python products. For Zope Products written in Python, it would be useful to attach methods written in Perl. o (2) The transaction machinery works, meaning exceptions in Perl roll back transactions. Jim -- Whoa! This could mean a number of things. A simple interpretation is that exceptions are propigated. Is that what you mean? Exceptions in perl are propigated to Python exceptions. Jim -- A much more difficult interpretation is that perl data are handled in a transactional fashion. We may identify this as a need, but it might be really hard. I don't think that this is what you mean though. o (2) Works with ZPublisher's method invocation. The ORB sniffs at method signatures, and automatically gets those required arguments out of the request. The ORB then calls the method, passing in the arguments and raising an exception if something is missing. In the case of external methods, the external method wrappers inspect the published methods and create the meta-data needed by the ORB. It isn't necessary that the ORB be able to inspect the perl objects directly. It is adequate that the wrapper object, the ExternalMethod, inspect the perl object and make the necessary data available to the ORB. o (3) Set/get state from within Perl. What happens when a Perl EM decides to create an attribute on 'self'? It depends on whether the attribute being set is a simple object such as a string or a number or an array of simple objects, or a complex perl object. If the object being set is a simple object, then we should simply convert it to a Python object and save it. When we save it, we will do a Python setattr and the persistence machinery will have an effect. Setting complex perl objects is outside the scope of perl scripting. o (3) Works with ZEO, meaning a Perl object's state can be sent over the wire to a storage server. Jim -- I thought we weren't defining perl objects. I thought we were simply defining perl methods for Python objects. Contract What, beyond software specifications, are the other deliverables under the contract? o Jim -- Deliverables for whom? Questions o Digital Creations and Perl. What if we suddenly get a clamoring from customers that say, "OK, _now_ I love Zope, do my web app in Perl"? Jim -- We tell them to pound sand. :) Seriously, if it is simply a matter of expressing their business logic in perl, we do it. Perl isn't that hard to figure out. Or, if necessary, we hire someone. o DBI. Will the result of this allow Perl's great support for relational databases to be leveraged in Zope? If so, what are the cases where someone would not want to do this (e.g., is there an unacceptible performance/load hit)? Jim -- I suppose that this is possible. I don't know what the performance implications would be. I'd rather see someone do a decent job of DBI for Python. Or, for that matter, I'd be happy to see someone do a decent job of database support for Zope. I'm not convinced that DC shouldn't do this. Obviously, we shouldn't do this if we aren't willing to spend a bunch of resources on it. Of course, if someone could convince Active State that it is in their interest to maintain DBI for Python in the long haul, without DC money, then that would be much better.