With all this talk about wanting to use the filesystem to store Zope objects rather than the object database, I just wanted to underscore a point that has been mentioned, but mostly passed over. Zope objects are much more than simply text files. They are Python objects--so storing them in general requires something like a pickle. Documents and Folders can be approximated with filesystem directories and text files, however, they don't capture a lot of information like Zope object properties, permissions information, etc. In addition many objects like Database Connections don't map very well to a filesystem object at all. I've been thinking about these issues while working on FTP support, since FTP uses a filesystem metaphor for communication with Zope. For example, when you FTP an object in and out of Zope, you probably won't be putting and getting the complete object. You will be most likely putting and getting the textual or binary 'content' of the object. So while being able to import and export partial representations of Zope objects to and from the filesystem is an important convenience, I see big problems with it being a complete replacement for through the web editing. -Amos
On Wed, 30 Dec 1998, Amos Latteier wrote:
With all this talk about wanting to use the filesystem to store Zope objects rather than the object database, I just wanted to underscore a point that has been mentioned, but mostly passed over.
Zope objects are much more than simply text files.
They are Python objects--so storing them in general requires something like a pickle. Documents and Folders can be approximated with filesystem directories and text files, however, they don't capture a lot of information like Zope object properties, permissions information, etc. In addition many objects like Database Connections don't map very well to a filesystem object at all. Exactly. Just my talking. To get that feature (file system storage) one has to design it into the system from the beginning. And if the objects know from the beginning that they must be able to activate/deactivate themselves to something filesystem-like, then it works quite well :)
I've been thinking about these issues while working on FTP support, since FTP uses a filesystem metaphor for communication with Zope. For example, when you FTP an object in and out of Zope, you probably won't be putting and getting the complete object. You will be most likely putting and getting the textual or binary 'content' of the object. And that's not the same. You need more than one file to represent an object cleanly as text. For HTML-file objects for example I use at least three files: method.html .users .roles
For anything more complex, I use a complete directory. Actually, I'm considering if I should allow a more flexible class assignment for file'ish objects. Programming for directories as representation of an custom object makes it quite nice to program :)
So while being able to import and export partial representations of Zope objects to and from the filesystem is an important convenience, I see big problems with it being a complete replacement for through the web editing. Nothing that can be done to Zope at this point. You can try and succeed at a partial mapping, but that doesn't solve the basic problem: Zope objects do not have a ``defined'' external representation. Nice from some things, but not really acceptable for software development management. :(
Andreas -- Win95: n., A huge annoying boot virus that causes random spontaneous system crashes, usually just before saving a massive project. Easily cured by UNIX. See also MS-DOS, IBM-DOS, DR-DOS, Win 3.x, Win98.
On Wed, 30 Dec 1998, Andreas Kostyrka wrote:
but not really acceptable for software development management. :(
You keep saying this. I think you're stretching the point quite a lot. Any serious software development is going to be done on a filesystem with traditional tools in the form of Products and the occasional EternalMethod. Only the relatively trivial DTML and SQLMethods are stored in the database. And by storing them in the database you get simple revision control services free of charge in the form of Zope sessions and users. Zope isn't cool because it gives you new ways of doing all the stuff you already do. Zope is cool because it lets you do new things in ways you couldn't do before. If you just want to keep doing the same old stuff the same old way, well hell, do it! If I may be so bold as to say so, I think you're looking at everything from the wrong point of view. So CVS can't deal with objects. That's CVS's fault, not Zope's! Write a new tool that utilises the new technologies to replace CVS. We're all clever people here, after all. Mike. -- --- | Mike Pelletier Work: 519-746-1607 /opeware! | Software Developer Home: 519-725-7710 --- | mike@zopeware.com Fax: 519-746-7566 http://www.zopeware.com | Zopeware is not endorsed by Digital Creations
participants (3)
-
Amos Latteier -
Andreas Kostyrka -
Mike Pelletier