On Wed, 2004-04-14 at 19:14, Shane Hathaway wrote: > On Wed, 14 Apr 2004 [EMAIL PROTECTED] wrote: > > > My initial, uneducated thoughts on the topic were simplistic, but then I'm a > > big K.I.S.S. fan: simply pickle the entire object back and forth as one > > entity. This means for each object, there is one file on the fs. The > > benefit is greater simplicity ... the downside is that you couldn't check > > those files out of subversion and interact with them. I also have to > > imagine the former is faster ? > > If you store pickles, you can't merge, you can't store properties, in fact > you can't even store folders as directories or keep track of references > between objects. At that point, you'd do much better to just use > FileStorage--KISS, after all. Ape's real utility is in breaking objects > apart for storage. If you don't need that, you don't need Ape. But I > like to think it makes the job of breaking objects apart for storage > relatively simple. > > > But if usnig the latter, then I'd think that in SVN there would be only 1 > > file, written by a specific mapper for a specific content type, say image. > > the data written to the file is such that if checked out, the file "works", > > so I can open it in photoshop or something. > > > > I however, would simply put everything else in properties, if that makes > > sense at all. Zope properties, security information, and so on. 1 porperty, > > 1 piece of data. No need for reading/writing multi-line text. > > That's fine, although you'll need to distinguish Zope properties from > other kinds of properties. For example, if some object has a class_name > Zope property, you'd be in trouble if the system mixed that up with the > class_name key of the object classification.
Advertising
i don't think needs to much worrying about, just prefix zope properties with 'zope:' much the same way svn does with its properties 'svn:externals' > > > The only thing I'm not so sure about is this "remainder" ... Though if it > > really is a base64 encoded string, there's no reason not to put that in a > > property as well. > > That's correct, it's always base64 encoded (with some comments.) > > > The benefits I see: > > > > - The filesystem reflects the object structure, no extra files lying around. > > Definitely. > > > - a more consistent way to setup mappers/gateways: there's "data", and > > there's everything else. Have a common/defined/smart way of handling > > "everything else". > > I would recommend you defer this for a while. Lots objects don't > easily fit this model. For example, what is the "data" of a CMF tool? > We can make plenty of progress on Subversion without thinking about > changing the way mappers are defined. > > > - with the use of the properties related svn funtions, we better leverage > > SVN's features. > > Yup. > another thing to keep in mind here, svn is basically a versioned fs, and in addition to node/content history tracking and it has facilities/functions for apply deltas to content, and recieving delta diffs back etc, but these apply to node/content bodies and not to properties. ie. there are no facilties for diffing properties, and this would need to be implemented in python. -kapil _______________________________________________ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
