Ahhhh.... Oracle's approach to this is an add-on to 8i called IFS(Internet File System). It renders a database to http(woo...woo, Zope does this in its native functionality). Although, they are working on a renderer for native file systems. This would enable object methods for making files on the fly. As Zope already accomplishes this(rendering objects), thus presenting the view of the oo database is thus a filter. HTTP,FTP,CIFS,NFS,POP,IMAP all are protocols that speak the requesting clients language. Make Zope the engine and supply a framework in Zserver to plug in the server renderer. Samba is a great example. It renders between file systems quite well, although it is rather a tough and complex animal and very specialized. Although it would work along the same lines. Actually, there is a PERL module to simulate file systems already. It could be good start. Considering that most file viewing on Windows is moving to HTML, the Network Drive is looking more and more like a simple security login with a connection that is persistent, rather than actually mapping the drive. A distributed (native-CIFS/NFS) file system would change the industry. Actually it already has (http) through a browser window. I am wondering when it will occur as seamlessly as not having to be in a browser. If an ORB existed that could render data to the requesting protocol, it would be a great product, I think ZOPE could do this through the ZServer architecture. The Server in this case is the renderer, the ORB is the fulfillment component and the OO Database is the storage mechanism. The protocol plug-in is stored in Zserver and renders the appropriate view of the data. PROTOCOL | SERVER | ORB | OO DATABASE | </OS ADD-ON CLIENT> HTTP | ZSERVER | --- ZOPE --- | Client dependencies FTP | ZSERVER | --- ZOPE --- | Applications designed to be client/server!!! IMAP | ZSERVER | --- ZOPE --- | POP | ZSERVER | --- ZOPE --- | </OS ADD-ON CLIENT> <OS NATIVE> CIFS | ZSERVER | --- ZOPE --- | No Client dependencies - Native Applications NFS | ZSERVER | --- ZOPE --- | CLIENT/SERVER functionality yet no dependencies! </OS NATIVE> OS support is the dependency! If the rendering engine were modular, ZOPE would always be first in delivering support for new protocols and client functionality(DAV Support!!!), without changing the structure of the underlying database. The data exchange between the ZSERVER AND ZOPE would have to be managed. "You wouldn't want to serve a POP client an Excel file unless it is an attachment just as you wouldn't want to render a query to a FILE SYSTEM accept ones that have been designated as OK." Get It? It would save the world a little time and effort if one system could render data to a diverse set of clients. Rather than making a new server every time a new client arrives. I could simply build a layer of translation(XML) for a client and BINGO! New client/server. At the Native OS level this has the most power. Rendering live data into an Excel file on the fly is a real world application that would be a huge hit right now. "I want this months sales report... open Sales.xls BINGO!!! The data is there." I would really like to edit html in Dreamweaver as I regularly do and have it render into Zope. If you had file system level support every known application could be stored inside of Zope or have access to the data inside of ZOPE. Here is the interesting one: If you can have direct file access you could: Open a client application out of an oo database that rendered a view of the database back at you. (Sounds awfully like an OS!!!) Just Thoughts..... Theodore E. Patrick email: tpatrick@indigonetworks.com <mailto:tpatrick@indigonetworks.com> phone: 615-777-0070 ext.125 Indigo Networks - The Ultimate Choice In Who Sees You. http://www.indigonetworks.com -----Original Message----- From: Ross J. Reedstrom [mailto:reedstrm@rice.edu] Sent: Tuesday, March 23, 1999 3:57 PM To: Zope Mailing List Subject: Re: [Zope] Zope Database in XML Theodore Patrick wrote:
What I am referring to is rendering objects in the ZOPE database to a file system view. The object database could be managed as a Network
Drive(except
that the view would be data in the ZOPE object database). You could through some translation (xml or other) render the object database to CIFS/NFS.
<snipped various interesting examples of filesystem access to zope>
I guess what I am asking is: Can Zope act like a CIFS/NFS file system(virtual file system) with a layer of translation for converting
Zope
Objects to File system objects directly (XML or other)?
You seem to be asking for a hybrid of Zope and Samba ;-) Seriously, we have Samba, so one answer would be a filesystem driver for the undelying OS that talks to the Zope server to get its information. This could be re-exported as a samba share, or NFS or AFS or Coda or what-have-you. I've been musing about it for linux for a little bit - I'm going to try and convince one of the bright sparks around here to take a crack at it. For NT hosted Zope, you'd need to write an equivalent filesystem driver - apparently the the SDK for that is ~$1000. Oh, and parts of this are already present in the ZServer - it talks FTP, and there was some discussion of exposing object properties as virtual docs of some sort. Check the list archives. Ross -- Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu> NSBRI Research Scientist/Programmer Computer and Information Technology Institute Rice University, 6100 S. Main St., Houston, TX 77005 _______________________________________________ Zope maillist - Zope@zope.org http://www.zope.org/mailman/listinfo/zope (For developer-specific issues, use the companion list, zope-dev@zope.org - http://www.zope.org/mailman/listinfo/zope-dev )