October 2001 - Zope-Dev

Re: [Zope-dev] ZPL2.0
by Chris Withers 14 Oct '01

14 Oct '01

> If your question was actually "why does anyone bother with GPL license > compatibility" then that is a separate discussion. Indeed ;-) Chris

1 0

READ_ONLY not passed to FileStorage from z2.py
by Mitchell L Model 14 Oct '01

14 Oct '01

[Zope 2.4.1] I believe there's a problem with the z2.py startup script in that the READ_ONLY flag is ignored by Zope/__init__.py (line 564, following the "# Import Zope (or Main)" comment). Line 110 of __init__.py creates a FileStorage object, but does not include the optional read_only argument to its constructor. I was trying to do some exploring inside python (by importing Zope) without stopping the Zope server that I had running on the same database. I couldn't figure out a way to import Zope with a read-only variable set, so I started analyzing what z2.py was doing. Eventually I realized that even starting z2.py with a -r argument caused the same problem. If this problem is fixed for z2.py, I'm hoping it would give me the hook I need to import Zope read-only.

1 0

RE: .INFO is now live
by DotInfoCentral.com 13 Oct '01

13 Oct '01

Dear Internet user, It's official! The new .INFO domain extension has officially been launched and real-time submissions are now being accepted for the first time at: http://www.DotInfoCentral.com The next Internet gold rush has just started with the introduction of the first new generic domain name on the Internet since 1984. Experts expect that millions of new domain names will be registered over the next few months as existing .com registrants and the general public find out about this exciting, new extension. Since real-time registration just started on October 01, 2001, there are still a lot of very good names available. The time to act is now! Visit: http://www.DotInfoCentral.com immediately to secure your name. "While .com names hold the most prestige, the next frontier is the new suffixes -.info, .biz, and .pro likely to become available later this year..." -BUSINESSWEEK MAGAZINE, April 16, 2001. DotInfoCentral.com is one of the leading .INFO registration services and is currently informing members of the Internet community of this important, landmark event. If you know of anyone who currently owns a .com name but has not registered for the .info equivalent yet, please advise them as soon as possible. DotInfoCentral.com also offers easy 3-step pre-registration services for the upcoming .BIZ, .NAME, and .PRO domains which are scheduled for launch very soon. ####################################################################### We strongly oppose the continued sending of unsolicited email and do not want to send email to anyone who does not wish to receive our special mailings. As a result, we have retained the services of an independent 3rd party to administer our list management and removal services http://www.autoemailremoval.com/cgi-bin/remove.pl This is not SPAM. If you do not wish to receive further mailings, please click this link. The removal administrator can then preclude your email address from future mailings. Auto Email Removal Company. Ref# 011005 #######################################################################

1 0

Zope on Apache (Zapache? Zopache?)
by James＠tacomait.com 12 Oct '01

12 Oct '01

I would like to see something like Apache and Zope together, because I use them on NT. Are you talking about making Apache run Zope out of the box? -James 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: {HYPERLINK "mailto:michel@zope.com"}michel(a)zope.com (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

1 0

GUF and SQL
by Andre Schubert 12 Oct '01

12 Oct '01

Hi all, I'am using GUF with ZSqlMethods and found out, that every time a object is accessed the sql-method is called, which means to me that if i have many objects in my dtml-doc, then it takes a long time it is rendered. Thats why i wrote a little Product, which has a AccessRule that makes User authentication over GUF. I added a user-cache in my Product, which stores AUTHENTICATION-Strings of authenticated-users a num of secs. 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. thanks as

2 2

Re: [Zope-dev] A modest proposal: Replace medusa with Twisted
by Tim Hoffman 11 Oct '01

11 Oct '01

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 068888 fax: +61 8 6210 1883 email: timh(a)zute.net

3 3

Re: [medusa] Twisted, medusa, ZServer, and VFS's
by Skip Montanaro 11 Oct '01

11 Oct '01

Donovan> ZServer grew out of Medusa.... I'm not sure how tightly tied to Donovan> Zope it is.... Not tightly at all. I use it completely independent of Zope. Donovan> My problem with Medusa is its http and ftp servers assume that Donovan> the VFS can deliver files wrapped in producers without Donovan> blocking. I believe Sam Rushing has said all along that Medusa is intended for I/O-bound situations. If you have producers that are computationally bound or that do I/O outside of the Medusa framework, you'll suffer. -- Skip Montanaro (skip(a)pobox.com) http://www.mojam.com/ http://www.musi-cal.com/

3 4

ZSQL methods lookup vars in REQUEST only (why?)
by Tim McLaughlin 11 Oct '01

11 Oct '01

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

5 6

Component model, webservices and xmlrpc?
by Jay, Dylan 11 Oct '01

11 Oct '01

This is a question for those that understand where the component model and webservices are headed with zope. I'm asking since I'm trying to understand the direction zope is headed 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 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. - 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?

2 1

RE: Component Architecture / A modest proposal: Replace medusa with Twisted
by Jean Jordaan 11 Oct '01

11 Oct '01

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.

2 1