Hi!

...

Can I ask for a comparison between Zope and Oracle Internet File System, if they are in competition and, if so, what are the strenghts of Zope and why I could prefer Zope?

Isn't this a bit like comparing apples and toiletpaper? :-) Oracle IFS is a server that serves files through a large variety of protocols, like NFS, SMB, HTTP, FTP; IMAP and so on. Zope is an object oriented internet application server.

Well, IFS can be used for things Zope can be used for, so why not compare them? I have no hands-on experience with IFS, but know it quite well in theory (reading relevant product reviews, white papers and the like). So I'll give it a try: If all you need is making your Oracle data available via one of the protocols IFS supports, then IFS is your choice. AFAIK, you'll not have to pay additional licensing fees if you already have an Oracle license. If you want to build applications, the choice (excluding others like PHP) is: Oracle + IFS (if you need it) + an application server of your choice (e.g. Oracle's, or BEA Weblogic, or IBM Websphere) or Zope + an RDBMS of your choice, if needed (Oracle, PostgreSQL, MySQL, ...) + additional servers of your choice, as needed (OpenLDAP, Cyrus IMAP, whatever) You see, it is getting complicated. Sometimes it might even be the most efficient to use Oracle + IFS + Zope, just because developing your application will be much faster in Zope than in any Java application server. Somtimes however, you'll not have the budget for Oracle, so you'll go with PostgreSQL/MySQL + Zope. While Zope can't do this out-of-the-box, it would be perfectly possible to use it to access PostgreSQL tables via WebDAV, IMAP, whatever, and in effect get the same features the IFS gives you for Oracle. What I currently wouldn't consider a sane choice is using Zope primarily as a file server (or "virtual file server", if we are talking about serving from an RDBMS). It's just not made for it, and Zope's performance is likely to be much worse than using specialised products. On the other hand, Oracle IFS is really eating memory and resources. AFAIK you should always run it on well-equipped dedicated servers. Zope running on such a server might be rather fast, too. To come back to your question: You'll have to start with examining the problem you are going to solve: If you can start from scratch, using open-source-only technology (I'd call my favourite one "ZAPP" - Zope, Apache, Python, PostgreSQL, like "LAMP" stands for the popular Linux, Apache, MySQL, PHP/Perl) might be the best choice. Why? Because it is open, cheap, and stands for real rapid development (which is my no. 1 reason for using Zope). If you already have Oracle in your business and IFS can solve the problem without having to write applications against it, it will be the best choice. Compare it to Samba: You'd never start writing SMB support for Zope and exporting your files via LocalFS + Zope + SMBForZope if you can do the same with Samba. Joachim

Hi!

I don't know to much about OIFS, but first of all you should consider that Zope's filesystem is a virtual file system stored in one single file (coming with usual advantages and disadvantages). As I remember to OIFS, it does not hold everything in one big file.

Oracle IFS stores stuff to an Oracle DB, that's what it was built for ;-) Zope stores stuff where you tell it to store stuff. If you use the ZODB, it stores to the ZODB (which can be a single file, or a BerkleyDB, or whatever implementation of ZODB you are using), if you use it with SQL RDBMS, it might store stuff there, and LocalFS or ExtFile store stuff to the file system ... (It's that easy, or that complicated, as you like it)

Another point at this comparison could be to find out whether Zope loads the whole file system to memory (as I was told) or not.

I am not the expert on this, but AFAIK, Zope holds some index tables in memory and loads objects into memory when needed, with some caching (e.g. an "objectValues" call will load all the objects in a folderish object like "Folder"). That's far from having the whole system in memory ;-) Joachim