- Why I don't think Zope will work for me
Zope is very cool. Zope has many useful features. But I believe that storing most of your useful data inside an opaque object database is a fatal flaw. I learned through painful experience that having your project data in text files in a filesystem is a Good Thing. You can use standard UNIX tools to manipulate these files. You can use EMACS or vi or any other tool to edit them. And most importantly, you can use CVS or RCS or any other similar tool for source control. I just don't see how you can build a large project with multiple developers using a Netscape browser as your editing tool, unless I'm missing something very obvious about the way Zope works. --Curtis
Curtis Galloway wrote:
Zope is very cool. Zope has many useful features. But I believe that storing most of your useful data inside an opaque object database is a fatal flaw.
This is a rather strong statement. I could say that requiring me (and my customers) to have access to the application file system, or to do without long-running transactions is a fatal flaw. But I won't. ;)
I learned through painful experience that having your project data in text files in a filesystem is a Good Thing. You can use standard UNIX tools to manipulate these files. You can use EMACS or vi or any other tool to edit them. And most importantly, you can use CVS or RCS or any other similar tool for source control.
I just don't see how you can build a large project with multiple developers using a Netscape browser as your editing tool, unless I'm missing something very obvious about the way Zope works.
We do it all the time. Of course, I'd much *rather* use emacs as my editing tool. When Zope has FTP support, then this will be possible. Actually, when FTP support lands, a number of interesting scenarios will be possible. Note that you don't absolutely have to use Zope's database if you don't want to. For example, you could use ZPublisher and DocumentTemplate without using the rest of the Framework. Of course, you'd lose alot of functionality, but you'd retain alot of cool benefits. It might be interesting if you or someone else came up with a kind of Zope folder that simply got it's objects from a file-system directory. Presumably, the subobjects would be made available as Zope objects that played within the Framework, but were actually stored in the file system. Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (540) 371-6909 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.
On Wed, 30 Dec 1998, Jim Fulton wrote:
Curtis Galloway wrote:
Zope is very cool. Zope has many useful features. But I believe that storing most of your useful data inside an opaque object database is a fatal flaw.
This is a rather strong statement.
I could say that requiring me (and my customers) to have access to the application file system, or to do without long-running transactions But I do not require file system access. The point is that I can use the filesystem (if I'm allowed too). Even better I can upload an .tar.gz of the whole site at once, ... is a fatal flaw. But I won't. ;)
I learned through painful experience that having your project data in text files in a filesystem is a Good Thing. You can use standard UNIX tools to manipulate these files. You can use EMACS or vi or any other tool to edit them. And most importantly, you can use CVS or RCS or any other similar tool for source control.
I just don't see how you can build a large project with multiple developers using a Netscape browser as your editing tool, unless I'm missing something very obvious about the way Zope works.
We do it all the time. Of course, I'd much *rather* use emacs as my editing tool. When Zope has FTP support, then this will be possible. Actually, when FTP support lands, a number of interesting scenarios will be possible. Not really. FTP is not acceptable as it unencrypted. ;) That doesn't work to well with my paranoia. (Sorry, some of this paranoia even lingers around when my sysadmin hat is stowed away *g*)
Note that you don't absolutely have to use Zope's database if you don't want to. For example, you could use ZPublisher and DocumentTemplate without using the rest of the Framework. Of course, you'd lose alot of functionality, but you'd retain alot of cool benefits.
Some of the functionality. But then, CVS and staging servers work REALLY WELL with dialup connectivity, while versioning in the production server requires me to be online during the work, ... (As it is the production server, I just cann't copy over the database files and replace them later, some user might changed the database, right?)
It might be interesting if you or someone else came up with a kind of Zope folder that simply got it's objects from a file-system directory. Presumably, the subobjects would be made available as Zope objects that played within the Framework, but were actually stored in the file system. Actually, I've come up with a tiny Zope replacement :)
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:
Not really. FTP is not acceptable as it unencrypted. ;) That doesn't work to well with my paranoia. (Sorry, some of this paranoia even lingers around when my sysadmin hat is stowed away *g*)
Once Medusa ftp support is added, perhaps we (or rather those of us with reasonable governments) could develop an encryption package. SSH2 supports sercure ftp, and they are seeking IETF standardization. Mabey we could implement this standard in medusa's ftp server.
Actually, I've come up with a tiny Zope replacement :)
Any chance of letting us see it? :) --- John Eikenberry [jae@taos.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
On Wed, 30 Dec 1998, John Eikenberry wrote:
On Wed, 30 Dec 1998, Andreas Kostyrka wrote:
Not really. FTP is not acceptable as it unencrypted. ;) That doesn't work to well with my paranoia. (Sorry, some of this paranoia even lingers around when my sysadmin hat is stowed away *g*)
Once Medusa ftp support is added, perhaps we (or rather those of us with reasonable governments) could develop an encryption package. SSH2 supports The problem is, that these ``reasonable'' governments are bullied by someone into ``changing'' their minds. (Just read the comments from the finish government.)
But happilly, it seems that some Danish diplomat botched it for the EU :) (Because he signed without the agreement without authorization by his government or parliament, Danemark will have to object to these sad international aggreement in the EU commission, which will lead to a rejection on federal level. And imposing such crypto restriction on national level is quite surely against the EU ``constitutional'' law, which enshrines free trade ;) )
sercure ftp, and they are seeking IETF standardization. Mabey we could implement this standard in medusa's ftp server. Not a good idea. digicool is located in the most liberated country of the world. So it's much better not to have buildin crypto, much better to use external tools, like: Apache-SSL rsync/ssh CVS/ssh
As you notice, most of these prefer to work with filesystem trees ;)
Actually, I've come up with a tiny Zope replacement :)
Any chance of letting us see it? :)
Basically yes ;) I'd just have to clean it up a bit. Additionally, at the moment it's not that cool. (But it allows to publish Bobo objects basically by adding one line to the source ;) )
"A society that will trade a little liberty for a little order will deserve neither and lose both." --B. Franklin Sad that this one got lost one the actual administration (and previous ones). :(
Andreas
On Wed, 30 Dec 1998 andreas@mtg.co.at wrote: [...]
The problem is, that these ``reasonable'' governments are bullied by someone into ``changing'' their minds. (Just read the comments from the finish government.)
Where? What are you refering to?
But happilly, it seems that some Danish diplomat botched it for the EU :)
[...] I must say I haven't followed any of this, but it sounds interesting... Do you have a reference or something?
sercure ftp, and they are seeking IETF standardization. Mabey we could implement this standard in medusa's ftp server.
Not a good idea. digicool is located in the most liberated country of the world. So it's much better not to have buildin crypto, much better to use external tools, like: [...] Apache-SSL rsync/ssh CVS/ssh
It still would be nice to have a standard tool that worked with Zope (at least IMO.) I guess it would be possible to follow the route of pgp and have two versions etc... No? And personally -- I usually sit at the machine where the webserver is located, so it would be very nice to be able to edit the document methods directly in emacs... (I guess it would be possible to make an emacs-lisp program that interacted with Zope, but it seems a bit unneccesary...)
As you notice, most of these prefer to work with filesystem trees ;)
-- Magnus Lie Hetland www.pvv.org/arcadia <arcadia@pvv.org>
On Wed, 30 Dec 1998, Magnus Lie Hetland wrote:
On Wed, 30 Dec 1998 andreas@mtg.co.at wrote: [...]
The problem is, that these ``reasonable'' governments are bullied by someone into ``changing'' their minds. (Just read the comments from the finish government.)
Where? What are you refering to? What was it, War.... Agreement. That's basically an agreement to export control weapons and dual use stuff. And in this agreement, the US pushed for declaring crypto an weapon to be export controlled, and achieved their goal ;)
(I should have bookmarked the pages, I've come to the sites trough slashdot)
But happilly, it seems that some Danish diplomat botched it for the EU :)
[...]
I must say I haven't followed any of this, but it sounds interesting... Do you have a reference or something?
As this dangerous (to internet security) agreement is about limiting free trade, this has to be legislated on EU level. Seems like one representative (the Danish one) botched it up, which led to some turmoil in Danemark and it's Parliament -> So Danemark probably will not agree to this in the EU commission -> the legaslation will fail on EU level.
sercure ftp, and they are seeking IETF standardization. Mabey we could implement this standard in medusa's ftp server.
Not a good idea. digicool is located in the most liberated country of the world. So it's much better not to have buildin crypto, much better to use external tools, like: [...] Apache-SSL rsync/ssh CVS/ssh
It still would be nice to have a standard tool that worked with Zope (at least IMO.) I guess it would be possible to follow the route of pgp and have two versions etc... No?
Very much work. And the US Zope would not be allowed to have plugin APIs that would allow for crypto plugins, just see the Mozilla Crypto FAQ, where this is explained.
And personally -- I usually sit at the machine where the webserver is Doesn't work like this here. Personally I'd never work on something that old and slow as our webservers. (X11 & netscape & ... put quite a load on the system.) located, so it would be very nice to be able to edit the document methods directly in emacs... (I guess it would be possible to make an emacs-lisp That's what I'm doing now. Edit the documents, cvs commit, ssh server, cvs update -Pd. That's it :) But it works only with a file based representation *g* ;)
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.
Andreas Kostyrka wrote:
On Wed, 30 Dec 1998, Jim Fulton wrote:
Curtis Galloway wrote:
Zope is very cool. Zope has many useful features. But I believe that storing most of your useful data inside an opaque object database is a fatal flaw.
This is a rather strong statement.
I could say that requiring me (and my customers) to have access to the application file system, or to do without long-running transactions But I do not require file system access. The point is that I can use the filesystem (if I'm allowed too). Even better I can upload an .tar.gz of the whole site at once, ...
Would you allow both through the web editing and file system editing? How would this interact with CVS?
is a fatal flaw. But I won't. ;)
I learned through painful experience that having your project data in text files in a filesystem is a Good Thing. You can use standard UNIX tools to manipulate these files. You can use EMACS or vi or any other tool to edit them. And most importantly, you can use CVS or RCS or any other similar tool for source control.
I just don't see how you can build a large project with multiple developers using a Netscape browser as your editing tool, unless I'm missing something very obvious about the way Zope works.
We do it all the time. Of course, I'd much *rather* use emacs as my editing tool. When Zope has FTP support, then this will be possible. Actually, when FTP support lands, a number of interesting scenarios will be possible. Not really. FTP is not acceptable as it unencrypted. ;) That doesn't work to well with my paranoia. (Sorry, some of this paranoia even lingers around when my sysadmin hat is stowed away *g*)
Note that you don't absolutely have to use Zope's database if you don't want to. For example, you could use ZPublisher and DocumentTemplate without using the rest of the Framework. Of course, you'd lose alot of functionality, but you'd retain alot of cool benefits.
Some of the functionality. But then, CVS and staging servers work REALLY WELL with dialup connectivity, while versioning in the production server requires me to be online during the work, ... (As it is the production server, I just cann't copy over the database files and replace them later, some user might changed the database, right?)
Right, but you can export and import just the parts of the site you are working on.
It might be interesting if you or someone else came up with a kind of Zope folder that simply got it's objects from a file-system directory. Presumably, the subobjects would be made available as Zope objects that played within the Framework, but were actually stored in the file system. Actually, I've come up with a tiny Zope replacement :)
It is important to note that Zope includes technology formerly knows as Bobo as well as the higher level Zope framework. If you use ZPublisher and DocumentTemplate, you are using Zope. :) Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (888) 344-4332 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.
On Wed, 30 Dec 1998, Jim Fulton wrote:
Would you allow both through the web editing and file system editing? I allow both. Actually, that depends. I'm hosting some webservers where I do not allow local filesystem level access. (Although there is a Unix user behind the server, it does not have a password ("*"), nor a shell ("/bin/false"). What it does have is a home directory for the data, and an uid for quota.
How would this interact with CVS? Very well :) edit trough the Web is just another kind of edit.
But this whole thing depends heavily upon staging servers (I know, that's against the Z Zen.), and staging server work very well in our model where we do have usually only dialup access. I know, that might not be a concern in the US with free (as in free beer) local phone calls, BUT it matters here around. (Even if Internet access is relativly cheap at about USD4/hour during office hours in Austria.)
Right, but you can export and import just the parts of the site you are working on. But many people prefer use known tools :) I've got more than one talk where the customer has some REALLY stupid misconception about what they want to use. (Boy, was that talk interesting, about porting Bobo to the Java Servlet API. And no, I'm not talking about JPython :( )
It might be interesting if you or someone else came up with a kind of Zope folder that simply got it's objects from a file-system directory. Presumably, the subobjects would be made available as Zope objects that played within the Framework, but were actually stored in the file system. Actually, I've come up with a tiny Zope replacement :)
It is important to note that Zope includes technology formerly knows as Bobo as well as the higher level Zope framework.
If you use ZPublisher and DocumentTemplate, you are using Zope. :)
I'm using Bobo and DocumentTemplate's of pre Zope vintage :) As such we are not using Z ;) 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.
Hi, How about making a "crappy", "poorly produced", real "T-shirt style" VHS tape of a session creating some small application where a simple object design is done through implementation... Sort of along the lines of me just walking into your offices (DCers in particular), asking you to demonstrate Zope to me, and you just sitting down at the keyboard, and allowing me to run my camera to record what is going on... have some "newbie" there to ask "dumb questions", etc... Get into "trouble" so that we can see the debugger in action (person and tool)... Just a thought... BTW, I have my check book along, and a stamped envelope (without address) that I was going to use to order Linux Journal today... but if this were to be available... Heck, you make the tape, and I'll dup/mail it to Zopesters at cost (or less) for a while... The tape could be "anonymous" if you wanted so that there would be no association or negative reflection with DC... Something quick and dirty to be replaced by more "formal" presentation, if DC ever thought it was needed. I'm not frustrated by what I've been able to download from Zope.org, but I am really thinking that if I could just "watch over the shoulder" of some Zope guru (Jim/Amos/Brian/Paul/all/any/other) for 5 to 10 minutes... that all the gaps I keep running into would seal up for me... I read/ask/try, get past one, hit the next... not sure what I've learned, what I haven't learned... Building a small gadfly based telephone directory that has some active logic in it (e.g. verify state code via stored procedure, have a "daemon" that sends e-mail about upcoming birthdays, have something that ensures specific fields are entered)... that'd be wonderful. My problem is I'm not clear in what I'm looking for relative to the Object nature of things... Is it "the same" as non-object, or is there something "more better" that the navigation of the Zope interface provides? -- Cheers, --ldl ----------------------------------------------------------------------------- LD Landis ldl@HealthPartners.Com N0YRQ Voice 612/883-5511 Fax 612/883-6363 HealthPartners, 8100 34th Avenue So, PO Box 1309, Minneapolis, MN 55440-1309 Shape your life not from your memories, but from your hopes. (Borrowed) -----------------------------------------------------------------------------
On Tue, 29 Dec 1998, Curtis Galloway wrote:
Zope is very cool. Zope has many useful features. But I believe that storing most of your useful data inside an opaque object database is a fatal flaw. *nod* :)
I learned through painful experience that having your project data in text files in a filesystem is a Good Thing. You can use standard UNIX tools to manipulate these files. You can use EMACS or vi or any other tool to edit them. And most importantly, you can use CVS or RCS or any other similar tool for source control. *nod* HOW can people live without CVS on single developer projects, and even worse on multiple developer stuff?
I just don't see how you can build a large project with multiple developers using a Netscape browser as your editing tool, unless I'm missing something very obvious about the way Zope works. Agreed :)
That's why I've build my own ``little'' (perhaps tiny would describe it better) Zope Clone, using only Bobo&DocumentTemplate. As you've notices I've left out BoboPOS, so you can guess where I'm storing my data. Yes, on the filesystem. (Not completly correct, as I'm using an filestorage API, I could (at least in theory) store the whole site or part of it somewhere else, be it an SQL server, be it something else ;) ) 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:
That's why I've build my own ``little'' (perhaps tiny would describe it better) Zope Clone, using only Bobo&DocumentTemplate. As you've notices I've left out BoboPOS, so you can guess where I'm storing my data. Yes, on the filesystem. (Not completly correct, as I'm using an filestorage API, I could (at least in theory) store the whole site or part of it somewhere else, be it an SQL server, be it something else ;) )
Once BoboPOS3 is out, with its cleaned up and stabilized API, wouldn't it be possible to build a replacement for it that uses the filesystem instead of the binary format? I thought one of the features of the new BoboPOS was that it would allow alternative storage methods... --- John Eikenberry [jae@taos.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 wrote:
On Wed, 30 Dec 1998, Andreas Kostyrka wrote:
That's why I've build my own ``little'' (perhaps tiny would describe it better) Zope Clone, using only Bobo&DocumentTemplate. As you've notices I've left out BoboPOS, so you can guess where I'm storing my data. Yes, on the filesystem. (Not completly correct, as I'm using an filestorage API, I could (at least in theory) store the whole site or part of it somewhere else, be it an SQL server, be it something else ;) )
Once BoboPOS3 is out, with its cleaned up and stabilized API, wouldn't it be possible to build a replacement for it that uses the filesystem instead of the binary format?
I'm not sure what you mean by "replacement for it".
I thought one of the features of the new BoboPOS was that it would allow alternative storage methods...
It provides an abstract low-level storage interface. This interface maps opaque ids to pickles. People who want to use the file system don't want opaque ids and pickles. They want file paths and text files. I could imagine fitting some file-based "database" into the ZODB framework, although it would need to interface at a higher level. One significant disconnect is that in the ZODB way of thinking, storage location is independent of location in the objects space. For a file-system-based database, the two would be tightly connected. Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (888) 344-4332 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.
participants (8)
-
Andreas Kostyrka -
andreas＠mtg.co.at
-
Curtis Galloway -
Jim Fulton -
Jim Fulton -
John Eikenberry -
LD Landis -
Magnus Lie Hetland