RE: [Zope] Some tough questions about zope... (long)
-----Original Message----- From: Tony McDonald [mailto:tony.mcdonald@ncl.ac.uk] Sent: Wednesday, March 03, 1999 9:42 AM To: zope@zope.org Subject: [Zope] Some tough questions about zope... (long)
Hi all, This is quite a long email where I ask a lot of questions about Zope, but I hope you'll be lenient with me as I think I have a few hard decisions to make!
Some background: I'm one of the web developers here, with a remit to implement a curriculum database that can; (a) support the Medical Faculty here (b) get rolled out to three other Medical-related sites, each with their own 'look and feel' (c) possibly implement a University-wide curriculum database.
I've read a lot of the documentation, and am doing so constantly, but the wisdom of the list would be very helpful indeed.
If you continue to use it you will get the Zope Zen. :)
The questions: a) Is there a way for us to 'dump' the non-dynamic parts of a Zope database into static HTML pages. This would act as a way to say to the team "look, we have a parachute!".
This begs the question we've asked around here so many times, 'What is data?' Everything in Zope is Dynamic, in my thoughs, 'non-dynamic' is a Document with not DTML in it. But there is no way for Zope to sniff a document and see if it contains dynamic structures or not. Perhaps what could be done is to write a simple MyDocument that you stipulate in policy never to have dynamic stuff in it, and then write a crawler scripts that sucks out all such documents into a local file structure. There maybe easier solutions.
b) Can I integrate with the Perl/PHP3 programs that we have (the Perl programs are mainly .cgi, but the PHP3 programs are server-side scripted, and as such are embedded into the HTML itself). This is so that I can
...do what? ;) Zope can call your cgi scripts just like they are, as URLs. They would, of course, have to be external to Zope and if you have a bunch of little ones you may find it better (and a damn sight easier) to rewrite them as Python in Zope as external methods. (DTML is also a rather powerful language for being so simple). Just leave your PHP stuff in your documents; Zope will parse out the DTML and return it to the server, which will parse out the PHP stuff and return it to the browser. In fact, you can probably make DTML and PHP work together nicely and simplify much of your PHP code. In the quickie case you don't need to change your PHP.
c) Is there any way of using the XML documents that I'm creating into the database and parsing them to produce either HTML or RTF output?
Zope doesn't contain an XML parser. You would need to do this with an external package.
d) I know that this a terrible question to ask... but is Zope likely to 'remain' open-source (we're worried about getting stuck with a proprietary system)?.
Yes.
e) Can I 'point' an Apache virtual server to run a Zope cgi (ie dropping the :port requirment).
Yes.
f) I'd like to have the option to have user authentication information coming from a database - is this possible?
Yes. There is an unsupported open source User Folder Product called UserDB, where you tell it how to query your DB and it uses that for authentication.
g) We have something like 200 main level directories holding the study guides, each with up to 200 files in them - is that pushing the Zope database too far?
Not at all.
h) We also need resources such as QuickTime movies, images PowerPoint slides etc. to be uploaded - would they sit in the database or can they be held somewhere else (and what happens about file name conflicts)?
ooo. Someone has yet to write an ExternalFile product (though I suspect it would be fairly simple) to add objects to the db that refer to files outside the db. For now you can upload them as File objects to be contained entirely in the db. The same rules that apply to file name conflicts in, say, a UNIX filesystem, apply to the Zope db. You can't have the same object id in the same folder. (With a minor non-exception of aquisition, all lower folders can see the contents of higher folders, but if you place an object in a lower folder with the same id as an object in a higher folder the lower object will override the higher object. Get that?)
i) Does Zope have the equivalent of 'server logs', which we use for research.
Since Zope is served through a web server you can continue to use the server logs. In other words, No. ;) Object by Object logging is something we've discussed, but would require *a lot* of thought and work.
j) Is it possible to have a 'pointer' at a location in the Zope database that will point to a 'real, honest to goodness' HTML file on the server (ie something like a redirect..oops I think I may have answered my own question)
If that file is being served up by Apache then you can just use it's URL as a 'pointer'.
and lastly k) What kind of loads have people put Zope under (10,000 +hits a day, 100k?). We have one application which has 170 Medical Students sitting in front of screens and clicking a button at the same time (they're selecting their final year options) which then starts 170 CGI-based Perl processes off interrogating and updating the database. This really grinds the system down...
Ah yes, the inevitable benchmarking question. There are lots of issues here, memory footprint vs processor speed vs concurrent access...etc. The quick word is, Zope is fast and it will get much faster. Zope is currently not concurrent but will be in 2.0. Zope+Apache is a bit slow due to the pcgi bottleneck and is much improved by using ZServer. As it stands now, ZServer is something like twice to 10 times faster than Zope+Apache. Medusa (the web core of ZServer) serializes the requests into Zope at the moment, but when 2.0 comes out it will be the fastest web application platform on earth. Don't quote me.
I hope that I haven't bored everyone to tears here - it's just that Zope seems to do an awful lot of what I need, and I'd really like to know what I'm letting myself in for if I start using it for everything I do....
No problemo.
many many thanks, tone.
-Michel
------ Dr Tony McDonald, FMCC, Networked Learning Environments Project The Medical School, Newcastle University Tel: +44 191 222 5888 Fingerprint: 3450 876D FA41 B926 D3DD F8C3 F2D0 C3B9 8B38 18A2
_______________________________________________ Zope maillist - Zope@zope.org http://www.zope.org/mailman/listinfo/zope
This sounds like something we need. I know that I could use it. If folks will critique this design, I'll implement it. - - Proposed Access Method - - It is desired to be able to have "non DTML" files incorporated in a Zope URL system. These files might be static GIF files, quicktime movies, or just plain old HTML. Obviously, they might be "included" in a DTML page by simply referencing them directly by their URL. However, I can see cases where one would like the access to be under the control of the Zope system. For example, access controls might apply. I believe that we can achieve this by having an object which represents an ExternalFS mount point. In general, we map a URL onto a node of the FS. It would be directly analogous to a symbolic link (ln -s). The Zope mount point would enforce permissions just as if the file were loaded into the Zope DB. Objects can be "imported" without having them take up space in the database. Their creation and maintanence can be handled outside the Zope system. They are rendered by "cat"ing their contents. By permitting substitutions in the link, we can create effective reformatting of the visible FS. As an example, I am monitoring customer traffic. "mrtg" automatically generates graphs for each customer. In Zope, I could create customized displays by importing these files. By using the ExFS, I can update the graphics without affecting Zope. Further, assuming /mygraphs/today/customer1.gif /mygraphs/today/customer2.gif /mygraphs/yesterday/customer1.gif /mygraphs/yesterday/customer2.gif we can map them onto somewhere/KustomerA/graphs/today somewhere/KustomerA/graphs/yesterday by substituting a property of the Kustomer - - - Thoughts and/or suggestions? Richard On Wed, 3 Mar 1999, Michel Pelletier wrote:
ooo. Someone has yet to write an ExternalFile product (though I suspect it would be fairly simple) to add objects to the db that refer to files outside the db. For now you can upload them as File objects to be contained entirely in the db. The same rules that apply to file name conflicts in, say, a UNIX filesystem, apply to the Zope db. You can't have the same object id in the same folder. (With a minor non-exception of aquisition, all lower folders can see the contents of higher folders, but if you place an object in a lower folder with the same id as an object in a higher folder the lower object will override the higher object. Get that?)
On 3 Mar 99, at 10:47, Richard Wackerbarth wrote:
This sounds like something we need. I know that I could use it. If folks will critique this design, I'll implement it.
Time to move this to zope-dev? anyway, I think this sounds like a good idea. It harkens back to an inquiry I made about byte-serving PDF files. I don't want to dump my pdf's into the database. If you can implement this, I think I could implement byte-serving. Although byte-serve could be handled at the ZServer level, I think for large external files it'd be more effective at the "cat" level -B Brad Clements, bkc@murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax netmeeting: ils://ils.murkworks.com ICQ: 14856937
On 03-Mar-99 Brad Clements wrote:
On 3 Mar 99, at 10:47, Richard Wackerbarth wrote:
This sounds like something we need. I know that I could use it. If folks will critique this design, I'll implement it.
Time to move this to zope-dev?
anyway, I think this sounds like a good idea. It harkens back to an inquiry I made about byte-serving PDF files. I don't want to dump my pdf's into the database.
If you can implement this, I think I could implement byte-serving.
Although byte-serve could be handled at the ZServer level, I think for large external files it'd be more effective at the "cat" level
How safe would it be, to allow any random user to use the add menu to create arbitrary symlinks into the native file system tree? --- Julian Morrison Programmer (Zereau Ltd)
Hi Richard,
This sounds like something we need. I know that I could use it. If folks will critique this design, I'll implement it.
I don't know if my critiques will be all that useful (being a Zope newbie), but hopefully this will help a bit.
- - Proposed Access Method - - It is desired to be able to have "non DTML" files incorporated in a Zope URL system. These files might be static GIF files, quicktime movies, or just plain old HTML.
Yes.
Obviously, they might be "included" in a DTML page by simply referencing them directly by their URL. However, I can see cases where one would like the access to be under the control of the Zope system.
Definitely. We have dozens and dozens (eventually hundreds) of files (QT movies, PowerPoints, Word Docs and the like - the mean size is about 600k-1Meg, but we have quite a few monsters at 6-7 Megs).
For example, access controls might apply.
I think that this is 'a good thing'.
The Zope mount point would enforce permissions just as if the file were loaded into the Zope DB.
Objects can be "imported" without having them take up space in the database. Their creation and maintanence can be handled outside the Zope system.
This would be excellent news for us.
They are rendered by "cat"ing their contents.
Does this ensure that MIME types are kept with the document, so that 'clicking' on its link will ensure that the correct helper application is invoked? Cheers, Tone. ------ Dr Tony McDonald, FMCC, Networked Learning Environments Project The Medical School, Newcastle University Tel: +44 191 222 5888 Fingerprint: 3450 876D FA41 B926 D3DD F8C3 F2D0 C3B9 8B38 18A2
-----Original Message----- From: Tony McDonald [mailto:tony.mcdonald@ncl.ac.uk] Sent: Wednesday, March 03, 1999 9:42 AM To: zope@zope.org Subject: [Zope] Some tough questions about zope... (long)
b) Can I integrate with the Perl/PHP3 programs that we have (the Perl programs are mainly .cgi, but the PHP3 programs are server-side scripted, and as such are embedded into the HTML itself). This is so that I can
...do what? ;) Zope can call your cgi scripts just like they are, as URLs. They would, of course, have to be external to Zope and if you have a bunch of little ones you may find it better (and a damn sight easier) to rewrite them as Python in Zope as external methods. (DTML is also a rather powerful language for being so simple). Just leave your PHP stuff in your documents; Zope will parse out the DTML and return it to the server, which will parse out the PHP stuff and return it to the browser. In fact, you can probably make DTML and PHP work together nicely and simplify much of your PHP code. In the quickie case you don't need to change your PHP.
If this would work (having Apache parse the PHP code in the pages returned by Zope), you would save me a lot of painfull converting working PHP code (mainly database related) and I would gradually convert from PHP/Apache to Zope/Python/Apache. Pleaz tell me how this neat trick is done... (maybe some fiddling with the headers???) Hint: Creating a DTML Document/method with the following contents doesn't fool Apache in rendering PHP! <!--#var standard_html_header--> <h2>Give me the (PHP) money...</h2> Read the phpinfo between the lines... NOT!! <hr> <? phpinfo(); ?> <hr> <!--#var standard_html_footer--> -- <- Ronald Offerman | ron@offerman.cx <- Root Powered Carrot Munchers Ltd. Inc. SA AG BV "This is Linux Country. On a quiet night, you can hear Windows NT reboot!" "Daddy, why do those people have to use Microsoft Windows?" "Don't stare, son; it's not polite." "M$ Windows NT, an accident waiting to happen" "What goes up, must come down. Ask any system administrator." ".sig too big? Flame me, I'm cold!"
On Wed, 3 Mar 1999, Ronald Offerman wrote:
also a rather powerful language for being so simple). Just leave your PHP stuff in your documents; Zope will parse out the DTML and return it to the server, which will parse out the PHP stuff and return it to the browser. In fact, you can probably make DTML and PHP work together nicely and simplify much of your PHP code. In the quickie case you don't need to change your PHP.
If this would work (having Apache parse the PHP code in the pages returned by Zope), you would save me a lot of painfull converting working PHP code (mainly database related) and I would gradually convert from PHP/Apache to Zope/Python/Apache.
This can't be done currently. I researched this a while back, trying to get server side includes to work. There's actually an entry in the Apache FAQ about it: """ 9.How can I have my script output parsed? So you want to include SSI directives in the output from your CGI script, but can't figure out how to do it? The short answer is "you can't." This is potentially a security liability and, more importantly, it can not be cleanly implemented under the current server API. The best workaround is for your script itself to do what the SSIs would be doing. After all, it's generating the rest of the content. This is a feature The Apache Group hopes to add in the next major release after 1.3. """ Though this is about SSI, it basically means (I believe) that apache can't take back the output of a CGI for additional module handling. --- John Eikenberry [jae@kavi.com - http://taos.kavi.com/~jae/] ______________________________________________________________ "A society that will trade a little liberty for a little order will deserve neither and lose both." --B. Franklin
* John Eikenberry | | On Wed, 3 Mar 1999, Ronald Offerman wrote: | | > > also a rather powerful language for being so simple). Just leave your | > > PHP stuff in your documents; Zope will parse out the DTML and return it | > > to the server, which will parse out the PHP stuff and return it to the | > > browser. In fact, you can probably make DTML and PHP work together | > > nicely and simplify much of your PHP code. In the quickie case you | > > don't need to change your PHP. | > | > If this would work (having Apache parse the PHP code in the pages | > returned by Zope), you would save me a lot of painfull converting | > working PHP code (mainly database related) and I would gradually convert | > from PHP/Apache to Zope/Python/Apache. | | This can't be done currently. I researched this a while back, trying to | get server side includes to work. [...] | Though this is about SSI, it basically means (I believe) that apache can't | take back the output of a CGI for additional module handling. I haven't tried it, but it could possibly be done by running two Apaches: one which stands "in front of" the other. The front-side Apache would rewrite every access into a PHP wrapper-script which include()s a corresponding URL from the back-side Apache where the Zope things would be done. On the other hand, I really should be asleep now so all this _may_ be utter nonsense, but I do think it's possible. It may even be possible with a single Apache, but that's more hairy than I dare think about right now. Good night. (Btw, my suggested hack isn't in total disagreement with the quoted FAQ entry, because my hack surely won't work with SSI. PHP3 isn't an official Apache module, so they don't neccessarily mention things like this in their FAQ.) -- Øyvind Møll oyvindmo@pvv.ntnu.no
participants (8)
-
Brad Clements -
John Eikenberry -
julian＠zereau.net -
Michel Pelletier -
Oyvind Moll -
Richard Wackerbarth -
Ronald Offerman -
Tony McDonald