[Zope] Zope vs CVS (Re: [ZDP] OpenContent issues)

Michel Pelletier michel@digicool.com
Mon, 24 May 1999 09:48:58 -0400


> -----Original Message-----
> From: Alex Rice [mailto:alrice@swcp.com]
> Sent: Monday, May 24, 1999 12:21 AM
> To: jim@digicool.com
> Cc: zope@zope.org
> Subject: Re: [Zope] Zope vs CVS (Re: [ZDP] OpenContent issues)
> 
> 
> 
> On Wed, 19 May 1999 09:18:52 -0400,
> Jim Fulton <jim@digicool.com> said:
> 
> [stuff about CVS...]
> 
> Jim> Zope, on the other hand, is transaction oriented.  Zope tracks
> Jim> meta-data for transactions, not individual objects.  
> This is a much
> Jim> saner approach, IMO.
> 
> 
> But from a development point of view, it's it little rough going
> figuring out the alternatives to just typing DTML in an HTML
> form. Import and Export only can use pickled python objects right? In
> Visual Age you can import/export source code, compiled code, 
> or archived
> code.
> 

Zope is a development environment, but it is also a dynamic backend to
public network services.  It would be trivial to add a 'code' object and
allow that object to execute arbitrary python in the Zope process space,
but then there would be only this thin Basic authenticated security
mechanism to prevent others from puting arbitrary code directly into
your Zope.  This is not so say that Zope security is weak, it is quite
strong (the weakest link in the chain is acutally HTTP) and there are
stronger alternatives if you want to pay the cost of time and possible
money to impliment SSL.  If someone breaks into your Zope, all they can
do is munge up some objects and maybe restart, but you can allways go in
and roll-back the database to fix their damage.  There is no way for a
user to execute arbitrary code as the UID of the Zope process.  
All of those abilities require access to the underlying OS (External
Methods, Python Products, etc.) which is assumed to have a higher level
of access authority.

> In Zope the other methods add more complexity: FTP support is rough or
> broken, WebDAV is coming soon, Netscape PUT is rumored to 
> work, not that
> great. I have no idea how all these ways of editing zope objects map
> into the "transaction oriented" model which you speak of.

FTP support works like a charm here, the only thing I would like it to
do is traverse into ZClasses, and I'll be implimenting that sometime
after the 2.0 final release.  WebDAV is as complete as the RFC is, and
works quite well with SiteCopy and with what parts of the spec MSIE 5.0
impliments, never used Netscape PUT but once and it worked then, but
it's possible there are problems, I'd venture to guess they were
netscape problems because I had a hell of a time getting Netscape
publishing to work with Roxen about a year ago.  Since Netscape
publishing has left a bad taste in my mouth.

The ZODB is fully transactional.  This means that multiple object stores
can be called a 'transaction' and if one doesn't happen, then none of
them do, or if one is undone, they are all undone.  Essentialy
transactionality allows you to take a group of operations and make them
one atomic operation.  Many higher end relational databases support the
notion of transactions on records, Zope supports the notion of
transations on objects.

Transactions are most obviously a benefit for staged development, and
they are the mechanism behind versions, which allow you to work on a
personal 'copy' of the database and only commit the changes you've made
when you are sure the whole thing is working, thus 'commiting' the
transaction.

And because all of the work done in a version is one transaction, the
whole mess can be undone cleanly.

-Michel
> 
> Alex Rice    |    alrice@swcp.com    |    http://www.swcp.com/~alrice
>     Current Location: N. Rio Grande Bioregion, Southwestern USA
> 
> 
> 
> _______________________________________________
> 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 )
>