Re: [Zope] Idea: ZTest: Integrated Use-case based web site testin g.
Aside: Do you really need this within Zope if you can run a ZClient script with chron? While a scheduler within Zope isn't a bad idea, the infrastructure -- at least on Unix and NT -- is already there.
This probably shouldn't be inside Zope, as it could be pretty CPU intensive on occasion. The balance I would strike is to have an external application that uses ZClient to retrieve certain TYPES of objects and then works with them. Then you could manage it through the web, without having to have the actual threads inside Zope. Chris -- | Christopher Petrilli Python Powered Digital Creations, Inc. | petrilli@digicool.com http://www.digicool.com
At 11:22 AM 8/27/99 -0400, Christopher Petrilli wrote:
Aside: Do you really need this within Zope if you can run a ZClient script with chron? While a scheduler within Zope isn't a bad idea, the infrastructure -- at least on Unix and NT -- is already there.
This probably shouldn't be inside Zope, as it could be pretty CPU intensive on occasion. The balance I would strike is to have an external application that uses ZClient to retrieve certain TYPES of objects and then works with them. Then you could manage it through the web, without having to have the actual threads inside Zope.
Unfortunately, unless that external application is just calling a "find the next scheduled event and execute it" method, it doesn't scale conceptually. The really interesting (to me) applications for a scheduler require more-or-less arbitrary objects to schedule future execution of their methods.
On Fri, 27 Aug 1999, Phillip J. Eby wrote:
At 11:22 AM 8/27/99 -0400, Christopher Petrilli wrote:
Aside: Do you really need this within Zope if you can run a ZClient script with chron? While a scheduler within Zope isn't a bad idea, the infrastructure -- at least on Unix and NT -- is already there.
This probably shouldn't be inside Zope, as it could be pretty CPU intensive on occasion. The balance I would strike is to have an external application that uses ZClient to retrieve certain TYPES of objects and then works with them. Then you could manage it through the web, without having to have the actual threads inside Zope.
Unfortunately, unless that external application is just calling a "find the next scheduled event and execute it" method, it doesn't scale conceptually. The really interesting (to me) applications for a scheduler require more-or-less arbitrary objects to schedule future execution of their methods.
True - however doing things internally requires dealing with concurrent issues. Using ZClient or xmlrpc throws the burden on Jim ;-) The simplest idea I came up with is to have a thread internally that sleeps for a given number of seconds and then calls a simple urllib.urlopen with a URL pointing to Folderish Scheduler Product. The Scheduler product then executes registered objects (using whatever registration method) sequentially. But again .. I am not sure how security is to be dealt with. Should there be a special role, scheduler, or use proxy functionality? Pavlos
Christopher Petrilli wrote:
Aside: Do you really need this within Zope if you can run a ZClient script with chron? While a scheduler within Zope isn't a bad idea, the infrastructure -- at least on Unix and NT -- is already there.
This probably shouldn't be inside Zope, as it could be pretty CPU intensive on occasion. The balance I would strike is to have an external application that uses ZClient to retrieve certain TYPES of objects and then works with them. Then you could manage it through the web, without having to have the actual threads inside Zope.
If someone uses this enough to hog down their machine, they they should probably be using ZEO with any number of processes running in the scheduler loop. Any very serious usage is probably not very smart usage unless you have the captal to back up the work with hardware. I like the whole idea, actually. I think a large number of test cases can be solved with cron, but others can't, and in the absence of a cross patform solution I like the idea of a standard component with a nice management interface. Getting back to to original idea for this whole thing is testing. An internal heartbeat system is not such a bad thing, in fact there is one but I don't think it's documented anywhere, it's a hack with zdaemon anyway. I think this could be handy. -Michel
Chris -- | Christopher Petrilli Python Powered Digital Creations, Inc. | petrilli@digicool.com http://www.digicool.com
_______________________________________________ Zope maillist - Zope@zope.org http://www.zope.org/mailman/listinfo/zope
(To receive general Zope announcements, see: http://www.zope.org/mailman/listinfo/zope-announce
For developer-specific issues, zope-dev@zope.org - http://www.zope.org/mailman/listinfo/zope-dev )
At 13:12 30/08/99 -0400, Mikhail Terekhov wrote:
What is ZClient?
ZClient is a Zope module which you can find in your Zope installation at: zope/lib/python/ZPublisher/Client.py It allows Zope to be a HTTP client, to fetch information from other web sites, for instance. In order to use ZClient here at Hiperlogica we wrote this trivial external method: -- from ZPublisher import Client def hx_client(url = 'http://www.yahoo.com', username = None, password = None, **kw): '''acess to http servers''' if kw: return Client.call(url,username,password,kw)[1] else: return Client.call(url,username,password)[1] -- The return of Client.call is a tuple, containing a mimetools.Message object and the data. The mimetools.Message (a standard Python class) contains headers describing the data, including its MIME type. We are only using this to fetch data from HTML pages, so we only return the second part of the response (item [1]). A more robust solution would have to read some headers and act accordingly... You can call that external method from DTML like this: -- <!--#var standard_html_header--> <h2><!--#var title_or_id--></h2> <HR> <!--#var "hx_client('http://www.zope.org')"--> <HR> <!--#var standard_html_footer--> -- We have managed to do some cool things with ZClient, but there are two mysteries which still haunt me: 1) How could I invoke the Client.call() method from DTML directly? (I wrote the External method because I could not figure this out) 2) Why the first part of the data retrieved is truncated? (So far I've been lucky and never had to retrieve a full page, but only parts) I hope this is useful! And if anyone knows the answer to my two questions, any hints will be appreciated. Best regards, Luciano Ramalho
Yes, we can use the cron, actualy, it's my solution, i made a copy of the ZClient to my internal python, and used that to extract informations from the web to actualize my data base and i think that, if we are working with a great tool named zope, with visual interfaces and etc, we nedd a solution to this problem with the same great concept, based in classes and with a visual interface. Michel Pelletier wrote:
Christopher Petrilli wrote:
Aside: Do you really need this within Zope if you can run a ZClient script with chron? While a scheduler within Zope isn't a bad idea, the infrastructure -- at least on Unix and NT -- is already there.
This probably shouldn't be inside Zope, as it could be pretty CPU intensive on occasion. The balance I would strike is to have an external application that uses ZClient to retrieve certain TYPES of objects and then works with them. Then you could manage it through the web, without having to have the actual threads inside Zope.
If someone uses this enough to hog down their machine, they they should probably be using ZEO with any number of processes running in the scheduler loop. Any very serious usage is probably not very smart usage unless you have the captal to back up the work with hardware.
I like the whole idea, actually. I think a large number of test cases can be solved with cron, but others can't, and in the absence of a cross patform solution I like the idea of a standard component with a nice management interface.
Getting back to to original idea for this whole thing is testing. An internal heartbeat system is not such a bad thing, in fact there is one but I don't think it's documented anywhere, it's a hack with zdaemon anyway. I think this could be handy.
-- Mauricio Souza Lima <mauricio@hiper.com.br> Hiperlógica <http://hiper.com.br> Automação de web-sites | Website automation São Paulo | Brasil | Fone: +55-11-251-4894
participants (7)
-
Christopher Petrilli -
Luciano Ramalho -
Mauricio -
Michel Pelletier -
Mikhail Terekhov -
Pavlos Christoforou -
Phillip J. Eby