Re: [Zope-dev] ZODB for Java?
Ian Beatty wrote: Greetings. Does anyone know of a good (stable, reliable, fast enough for production use in a web app) ZODB-equivalent for persisting Java objects? www.jdocentral.com Thanks, ..Ian -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- Dr. Ian Beatty [EMAIL PROTECTED] Physics Education Researchvoice: 413.545.9483 Department of Physics fax: 413.545.4884 Univ. of Massachusetts AIM: (available upon request) Amherst, MA 01003-9337 USA http://umperg.physics.umass.edu/ -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- ___ 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 ) ___ 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 )
Re: [Zope-dev] ZPT in Zope Products
Wyatt Anderson escribió: Hello All, I am trying to use ZPT within a Zope Product I am trying to build. I want to test the container type I am addding to to determine what action to take. The following though from Products.PageTemplates.PageTemplateFile import PageTemplateFile def manage_addMyContainerForm(self, REQUEST): pt = None if self.meta_type in [‘ContainerType1’, ‘ContainerType2’]: pt = PageTemplateFile(‘zpt/addMyContainerForm’, globals()) else: pt = PageTemplateFile(‘zpt/containerError’, globals()) return pt.pt_render() This produces the following traceback in Zope: Traceback (innermost last): Module ZPublisher.Publish, line 100, in publish Module ZPublisher.mapply, line 88, in mapply Module ZPublisher.Publish, line 40, in call_object Module Products.MyContainer.MyContainer, line 17, in manage_addMyContainerForm Module Products.PageTemplates.PageTemplate, line 90, in pt_render - Module Products.PageTemplates.PageTemplateFile, line 73, in pt_getContext TypeError: 'str' object is not callable I’ve checked out the code in PageTemplate.py and PageTemplateFile.py and can’t figure out what is going on. The line in question is root = self.getPhysicalRoot() Is it possibly some security thing? My class is setDefaultAccess(‘allow’) for now. I’ve also tried simply return pt with no traceback but without the desired results as the object is returned. Thanks in advance, Wyatt Try return pt() Santi Camps ___ 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 )
RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely r evis ion based storage for Zope ?)
Oh, a very good idea indeed! We'll have to look at that eventually. The mechanism you describe is preferable, but it should be noted that subversion properties are easily accessible using the clients. So long as said properties are human readable/writable, that's also an option. The main issue for me (And many others I suppose), is the fact that every single object type I use is either completely custom, or a monkey patched version of a built-in type (Notably OFS.Image for instance). So there would have to be a reliable serializer for "other" objects, which I beleive you already have, so that's OK :) What happens is you write a new serializer, notably write a custom serializer for an object type you've already been using for a while, using the "default" one ? (Presumably because you WANT to be able to access the contents from other tools) I think I noticed that somewhere in the .properties file there was a note of the class used for serializing ... Is there a way for a serialized instance to remember which serializer was used ? Or does everything break when I change the definition of a serializer (Old instances can no longer be read) ? J.F. -Original Message- From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: 14/04/2004 7:39 PM Subject: RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely r evis ion based storage for Zope ?) On Wed, 14 Apr 2004 [EMAIL PROTECTED] wrote: > Fact is if one wanted a client to interact with a svn repository that stores > zope objects, it would need to be fairly specifically designed for it ... > How would a client (Say dreamweaver with a subversion plug-in) know that > when editing an image, the x and y size properties need to be updated ? What > if someone monkey patches the image type to add some other > property/attribute ? I would say Ape is quite good at accepting data from non-Zope-aware tools, and I'd like to make it better. The fact that Ape stores the image dimensions separately from the image content is an implementation decision in the serializer. You could instead tell the serializer to detect image dimensions when loading the object. The detection is a relatively inexpensive operation. Shane ___ 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 ) ___ 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 )
RE: [Zope-dev] zLOG is dead
[Chris McDonough] > There probably are no log-trawling tools. The output generated by zLOG > is basically unparseable. Alas, that hasn't stopped people from writing trawlers to analyze ZEO server and client logs. That one's going to be my headache "to fix"(*), and has some urgency since ZODB/ZEO's use of zLOG is the only reason Zope3 still needs the zLOG package. people-who-like-regexps-don't-understand-"perverse"-ly y'rs - tim (*) Unless someone decides to do it before I get to it. False hope is a way of life . ___ 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 )
Re: [Zope-dev] zLOG is dead
On Wed, 2004-04-14 at 18:53, Fred Drake wrote: > Keeping it simple is good, but I'd still like to see every logging subsystem > in code that ships with the Zope 2 core start with "Zope." This is a > potential backwards compatibility issue, though, since log-trawling tools are > already using the names currently generated, as inconsistent as they are. There probably are no log-trawling tools. The output generated by zLOG is basically unparseable. - C ___ 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 )
[Zope-dev] Re: Fw: Re: VerboseSecurity Zope2.7
On Thu, 15 Apr 2004, Arthur Chan Chi Chuen wrote: > I know you're pretty busy preparing the SVN stuff, but let me ask you a quick > question about VerboseSecurity. Sorry, I didn't mean to drop this. My inbox got too full. :-) > Someone online said the cvs.zope.org works in 2.7, but it's not. Alex Limi > has tried it and said it failed too. So, will VerboseSecurity has a > compatible version with 2.7 soon? I'm waiting for this cool product, it will > save my life. Well, a bunch of us are actively using the VerboseSecurity HEAD with Zope-2_7-branch. It works OK, except that you can't see the name of the permission. However, you can still see the roles, user, executable owner, proxy roles, etc. when an authorization failure occurs. Shane ___ 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 )
RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely r evis ion based storage for Zope ?)
cool, let me try the cmfsvnbrowser first thanks. =) Arthur On Wed, 14 Apr 2004 10:35:14 -0400, Jean-Francois.Doyon wrote > Well there you go, perfect :) > > -Original Message- > From: Kapil Thangavelu [mailto:[EMAIL PROTECTED] > Sent: April 14, 2004 6:49 AM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely > r evis ion based storage for Zope ?) > > On Tue, 2004-04-13 at 20:53, [EMAIL PROTECTED] wrote: > > Hello, > > > > Hmmm, well it's as stable as Ape and Subversion are respectively :) > > > > I wouldn't call it stable no, it's something I did over the long week-end > we > > just had, and that's about it :) > > > > Ape is at 0.8 and therefore becoming quite mature, I'd have to let others > > speak as to it stability however ... > > > > Subversion is also probably quite stable (It just reached 1.0), though I > > don't know how heavily tested it's been in a long running process (Might > it > > have some memeory leaks ?) ... > > the svn apache server model is a long running process and is fairly > stable on memory usage. the python bindings require doing some manual > memory management, but the pool api makes it easy to deallocate > arbitrary allocations safely. the cmfsvnbrowser code i ref'd early > has been in production by myself and others for almost a year and > runs with a stable memory footprint. > > -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 ) -- Open WebMail Project (http://openwebmail.org) ___ 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 )
[Zope-dev] Re: More arguments for "z" (was Re: [Zope3-dev] Zope and zope)
On Wed, Apr 14, 2004 at 03:53:43PM -0400, Jim Fulton wrote: | Other reasons I like "z": | | - Less noise in imports | | - Echos the "circle z" | | - The packages in "z" can be used for more than just Zope | | - Emphasizes the more "minimalist" nature of Zope 3 relative | to Zope 2 | | - "z" is a component of "zope" | | OK, I'm getting carried away. Sorry ;) None of these sound like a strong argument. I dont buy it. +1 for renaming Zope to zope2. +0.9 for philiKON idea of putting zope into src/zope. -- Sidnei da Silva <[EMAIL PROTECTED]> http://awkly.org - dreamcatching :: making your dreams come true http://plone.org/about/team#dreamcatcher Modeling paged and segmented memories is tricky business. -- P.J. Denning ___ 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 )
[Zope-dev] Re: [Zope3-dev] Re: Zope and zope
On 04/14/04 12:27, yuppie wrote: Jim Fulton wrote: But I think that this is a big problem. Backward compatibility for Z2 *is* important. It's too bad that lots of test files have to import Zope. Sigh. Why is that a *big* problem? - It's not nice to break tests, but that doesn't necessarily mean the products are broken. - AFAICT many products need some polishing and a new release for Zope 2.8 anyway. I'm with Yuppie. With fundamental changes occurring in ExtensionClass and ZODB, lots of products are going to need a small revision anyway. For example, we've already started changing "from ZODB import Persistent" to "from Persistence import Persistent" everywhere. The majority of products that need to import Zope will just change from: from Zope import app to: try: from zope2 import app except ImportError: # Pre-Zope 2.8 from Zope import app I think it's cool that Python makes that so easy to do. Shane ___ 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 )
RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely r evis ion based storage for Zope ?)
On Wed, 14 Apr 2004 [EMAIL PROTECTED] wrote: > Fact is if one wanted a client to interact with a svn repository that stores > zope objects, it would need to be fairly specifically designed for it ... > How would a client (Say dreamweaver with a subversion plug-in) know that > when editing an image, the x and y size properties need to be updated ? What > if someone monkey patches the image type to add some other > property/attribute ? I would say Ape is quite good at accepting data from non-Zope-aware tools, and I'd like to make it better. The fact that Ape stores the image dimensions separately from the image content is an implementation decision in the serializer. You could instead tell the serializer to detect image dimensions when loading the object. The detection is a relatively inexpensive operation. Shane ___ 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 )
RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely r evis ion based storage for Zope ?)
On Wed, 14 Apr 2004 [EMAIL PROTECTED] wrote: > Right now the fs implementation stores "script commands" that are cummulated > upon connect() (I think?), validated as best as possible upon vote() and run > upon finish(). I don't see why this couldn't be adapted to SVN txn's ... > connect() = start a txn, vote() = validation (what this entails needs to be > defined, could involve delta operations, revision number matching, etc ... > ?), finish() = commit the svn txn. The transaction script is necessary for exactly one thing: translation between OIDs and paths. I agonized over this for months, but translating OIDs to paths simply requires complex machinery like this. Also, there is only one reason we have to translate OIDs to paths: opening files by inode number is disallowed (and probably unreliable) in most operating systems. In Subversion, is it possible to read/write a versioned object by unique identifier rather than by path? If so, it's a great blessing and we don't need a transaction script. Shane ___ 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 )
RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely r evis ion based storage for Zope ?)
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. > 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 of 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. > - possibly better performance/simpler code by not needing the whole multiple > file management and read/write of text files. Heck the whole > AnnotatedFileSystem, thing could be dropped/replaced with a > PropertyFileSystem implementation of some kind maybe ?? I'd guess there's no need for any such thing in Subversion. I think your code might eventually share a lot of code with the fs package, but if you'd like to start by making a clean break from the fs package, by all means go ahead. Shane ___ 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 )
Re: [Zope-dev] zLOG is dead
On Wednesday 14 April 2004 10:45 am, Andreas Jung wrote: > For consitency: Zope.Products. > For lazy writers: Zope. X > > I prefer the second solution...everyone should know what are products and > what > are packages. In fact the name does not matter because you can see in the > traceback > where the error occurs. You don't get this information from the name > directly. I disagree. Not everyone that looks at the logs will be a site developer or Zope product or core developer. Keeping things explicit is reasonable. > Keep the product name as it is...means Products/ should use > Zope. as logger name. No need to introduce a new mapping. Keep it > simple. Keeping it simple is good, but I'd still like to see every logging subsystem in code that ships with the Zope 2 core start with "Zope." This is a potential backwards compatibility issue, though, since log-trawling tools are already using the names currently generated, as inconsistent as they are. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation ___ 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 )
[Zope-dev] ZPT in Zope Products
Hello All, I am trying to use ZPT within a Zope Product I am trying to build. I want to test the container type I am addding to to determine what action to take. The following though from Products.PageTemplates.PageTemplateFile import PageTemplateFile def manage_addMyContainerForm(self, REQUEST): pt = None if self.meta_type in [‘ContainerType1’, ‘ContainerType2’]: pt = PageTemplateFile(‘zpt/addMyContainerForm’, globals()) else: pt = PageTemplateFile(‘zpt/containerError’, globals()) return pt.pt_render() This produces the following traceback in Zope: Traceback (innermost last): Module ZPublisher.Publish, line 100, in publish Module ZPublisher.mapply, line 88, in mapply Module ZPublisher.Publish, line 40, in call_object Module Products.MyContainer.MyContainer, line 17, in manage_addMyContainerForm Module Products.PageTemplates.PageTemplate, line 90, in pt_render -Module Products.PageTemplates.PageTemplateFile, line 73, in pt_getContextTypeError: 'str' object is not callable I’ve checked out the code in PageTemplate.py and PageTemplateFile.py and can’t figure out what is going on. The line in question is root = self.getPhysicalRoot() Is it possibly some security thing? My class is setDefaultAccess(‘allow’) for now. I’ve also tried simply return pt with no traceback but without the desired results as the object is returned. Thanks in advance, Wyatt ___ 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 )
RE: [Zope-dev] More arguments for "z" (was Re: [Zope3-dev] Zope a nd zope)
+1 from me ! I'm always in favor of less typing :P Besides, you make good points :) J.F. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jim Fulton Sent: April 14, 2004 3:54 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: [Zope-dev] More arguments for "z" (was Re: [Zope3-dev] Zope and zope) Jim Fulton wrote: > Jim Fulton wrote: > > ... > >> Give the responses. I need to recast my question as a selection >> among alternatives. But, before I do that, we will need to consider >> alternatives a bit more. > > > OK, here's another. > > What about renaming the Zope 3 zope package to "z". > > - It fits with the expansion of "Zope": > "Z Object Publishing Environment". > > - It's short :) > > - *At this time* (but after the move to svn), it's not too hard to make > a change like this for Zope 3. Backward compatibility is not a big > issue. This will change when X3.0 is released, which is why I'm > bothering to deal with this now. > > - This was suggested a couple of years ago when coming up with the > Zope 3 package layout. > > Examples (from the buddydemo example): > > import z.interface > from z.app import zapi > from z.app.event import publish > from z.app.event.objectevent import ObjectModifiedEvent Other reasons I like "z": - Less noise in imports - Echos the "circle z" - The packages in "z" can be used for more than just Zope - Emphasizes the more "minimalist" nature of Zope 3 relative to Zope 2 - "z" is a component of "zope" OK, I'm getting carried away. Sorry ;) Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ 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 ) ___ 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 )
[Zope-dev] More arguments for "z" (was Re: [Zope3-dev] Zope and zope)
Jim Fulton wrote: Jim Fulton wrote: ... Give the responses. I need to recast my question as a selection among alternatives. But, before I do that, we will need to consider alternatives a bit more. OK, here's another. What about renaming the Zope 3 zope package to "z". - It fits with the expansion of "Zope": "Z Object Publishing Environment". - It's short :) - *At this time* (but after the move to svn), it's not too hard to make a change like this for Zope 3. Backward compatibility is not a big issue. This will change when X3.0 is released, which is why I'm bothering to deal with this now. - This was suggested a couple of years ago when coming up with the Zope 3 package layout. Examples (from the buddydemo example): import z.interface from z.app import zapi from z.app.event import publish from z.app.event.objectevent import ObjectModifiedEvent Other reasons I like "z": - Less noise in imports - Echos the "circle z" - The packages in "z" can be used for more than just Zope - Emphasizes the more "minimalist" nature of Zope 3 relative to Zope 2 - "z" is a component of "zope" OK, I'm getting carried away. Sorry ;) Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ 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 )
[Zope-dev] Re: [Zope3-dev] Zope and zope
Marius Gedminas wrote: On Wed, Apr 14, 2004 at 11:06:37AM -0400, Jim Fulton wrote: What about renaming the Zope 3 zope package to "z". Examples (from the buddydemo example): import z.interface from z.app import zapi from z.app.event import publish from z.app.event.objectevent import ObjectModifiedEvent -1 for purely aesthetic reasons (IOW, I'm used to zope.something). Is this really just a matter of what you're used to? If you didn't have lots of experience typing "zope", would typing "z" instead really bother you? I actually like the z by itself. Perhaps because it echos the "circle z". I think I also like it because it seems to add less noise to the import lines. For example, I think I actually prefer: import z.interface from z.app import zapi from z.app.event import publish from z.app.event.objectevent import ObjectModifiedEvent to: import zope.interface from zope.app import zapi from zope.app.event import publish from zope.app.event.objectevent import ObjectModifiedEvent Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ 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 )
[Zope-dev] Re: [Zope3-dev] Zope and zope
On Wednesday 14 April 2004 10:52 am, Jim Fulton wrote: > packages become very unsttractive. It turns out that pkgutil will be > confused by the Zope package on Windows or Mac OS, adding it's directory > to the zope package's path. This is a bug in pkgutil that can be fixed, > but it is an example of the sorts of problems we can expect. I've filed a bug report on pkgutil: http://www.python.org/sf/935117 -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation ___ 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 )
[Zope-dev] how to get the icon of a product
Hi I try to get the icons of the installed products I try to get it with the self.all_meta_types()/instance/icon My better result is something like: misc_/Audio/mp3.gif with these path I can use: self.unrestrictedTraverse(icon) where icon is the path above (misc_/Audio/mp3.gif) With these approach some icons are correct other are not found is there any good way to get these info? Thanks a lot!! ___ 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 )
[Zope-dev] Re: Zope and zope
Jim Fulton wrote: Chris McDonough wrote: > I think the breakage, although literally "incalculable" (as is every change to Zope 2, given that it has no canonical API), would be manageable given enough lead time. In fact, if we did change the module name, we could just leave a "bruce" package in place that, when imported, raised a "ObsoleteError" with a descriptive message. But I think that this is a big problem. Backward compatibility for Z2 *is* important. It's too bad that lots of test files have to import Zope. Sigh. Why is that a *big* problem? - It's not nice to break tests, but that doesn't necessarily mean the products are broken. - AFAICT many products need some polishing and a new release for Zope 2.8 anyway. Cheers, Yuppie ___ 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 )
Re: [Zope-dev] zLOG is dead
On Wednesday 14 April 2004 11:44 am, Lennart Regebro wrote:
> Yeah, but is it reasonable to think that people who write new products
> will do this? A rule that most people will break is a bad rule... That
> people working on Zope itself can be well versed enough to use Zope.
> for things in teh Zope repository seems reasonable. But will people
> working on Plone really use "Zope.CMFQuickInstaller"? Rather they will
> probably say just "CMFQuickInstaller", "CMF.QuickInstaller" och
> "Plone.QuickInstaller" or something.
I would only expect any sort of leading "Zope." to apply to the software that
ships as part of Zope 2. Other products and tools, like the CMF and Plone,
should use a different prefix ("CMF." and "Plone." come to mind as reasonable
candidates).
-Fred
--
Fred L. Drake, Jr.
PythonLabs at Zope Corporation
___
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 )
Re: [Zope-dev] Re: [Zope3-dev] Re: Zope and zope
On Wednesday 14 April 2004 11:44, Barry Warsaw wrote: > On Wed, 2004-04-14 at 11:18, Stephan Richter wrote: > > Because in general I don't like version numbers in the path. I also think > > that "zope" is the only name that is 100% right on. Everything else is a > > compromise I would try to avoid. We will be sorry about it later, when > > many more people run Zope 3 only applications. > > I tend to agree, but if compromise is the only solution, then I'd tend > to favor keeping Zope3 'clean'. We're planning on Zope3 being around > much longer than Zope2, right? :) Yes, this is really what I meant. I want to keep Zope 3 clean too. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ 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 )
Re: [Zope-dev] Re: [Zope3-dev] Re: Zope and zope
On Wednesday 14 April 2004 11:36, Jim Fulton wrote: > > Again, I think educating is easier than anything else. People understand > > that this is due to a merge of codebases and is for a transition period > > only. And, the TTW scripter will not care. > > But this is a really important transition. It's a transition > that will last at least a year or two, maybe longer, and will be an > extremely sensitive period. I want things to go really well during > this transition. Me too! And I think some good transition documents can help explaining this. I will commit to writing them with the help of someone who knows Zope 2 well. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ 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 )
[Zope-dev] Re: [Zope3-dev] Re: Zope and zope
On Wed, 2004-04-14 at 11:18, Stephan Richter wrote: > Because in general I don't like version numbers in the path. I also think that > "zope" is the only name that is 100% right on. Everything else is a > compromise I would try to avoid. We will be sorry about it later, when many > more people run Zope 3 only applications. I tend to agree, but if compromise is the only solution, then I'd tend to favor keeping Zope3 'clean'. We're planning on Zope3 being around much longer than Zope2, right? :) onions-are-tasty-but-not-in-the-varnish-ly y'rs, -Barry ___ 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 )
Re: [Zope-dev] zLOG is dead
From: "Andreas Jung" <[EMAIL PROTECTED]> > Keep the product name as it is...means Products/ should use > Zope. as logger name. No need to introduce a new mapping. Keep it > simple. Yeah, but is it reasonable to think that people who write new products will do this? A rule that most people will break is a bad rule... That people working on Zope itself can be well versed enough to use Zope. for things in teh Zope repository seems reasonable. But will people working on Plone really use "Zope.CMFQuickInstaller"? Rather they will probably say just "CMFQuickInstaller", "CMF.QuickInstaller" och "Plone.QuickInstaller" or something. As with all management, people will do what seems natural to them, unless it doesn't work. There is no incentive to stick a "Zope." at the front, so I don't think people will. Besides, there is a benefit in not doing it, because then you can see what is a part of Zope and what is add-ons. ___ 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 )
[Zope-dev] Re: [Zope3-dev] Re: Zope and zope
Stephan Richter wrote: On Wednesday 14 April 2004 11:08, Jim Fulton wrote: ... What about "z.app.foo" or "z.i18n"? The shortness of this example is very attractive, but it is still a compromise in my opinion. Again, I think educating is easier than anything else. People understand that this is due to a merge of codebases and is for a transition period only. And, the TTW scripter will not care. But this is a really important transition. It's a transition that will last at least a year or two, maybe longer, and will be an extremely sensitive period. I want things to go really well during this transition. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ 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 )
Re: [Zope-dev] ZODB for Java?
hi, you should search on freshmeat.net. -aj --On Montag, 12. April 2004 16:05 Uhr -0400 Ian Beatty <[EMAIL PROTECTED]> wrote: Greetings. Does anyone know of a good (stable, reliable, fast enough for production use in a web app) ZODB-equivalent for persisting Java objects? Thanks, ..Ian -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- Dr. Ian Beatty [EMAIL PROTECTED] Physics Education Researchvoice: 413.545.9483 Department of Physics fax: 413.545.4884 Univ. of Massachusetts AIM: (available upon request) Amherst, MA 01003-9337 USA http://umperg.physics.umass.edu/ -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- ___ 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 ) ___ 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 )
[Zope-dev] Re: [Zope3-dev] Zope and zope
On Wed, Apr 14, 2004 at 11:06:37AM -0400, Jim Fulton wrote: > What about renaming the Zope 3 zope package to "z". > > Examples (from the buddydemo example): > > import z.interface > from z.app import zapi > from z.app.event import publish > from z.app.event.objectevent import ObjectModifiedEvent -1 for purely aesthetic reasons (IOW, I'm used to zope.something). Marius Gedminas P.S. I used to think ZOPE was a recursive acronym for the ZOPE Object Publishing Environment. -- Favorite MS-DOS error message: "Drive C: not ready, close door." signature.asc Description: Digital signature ___ 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 )
[Zope-dev] ZODB for Java?
Greetings. Does anyone know of a good (stable, reliable, fast enough for production use in a web app) ZODB-equivalent for persisting Java objects? Thanks, ..Ian -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- Dr. Ian Beatty [EMAIL PROTECTED] Physics Education Researchvoice: 413.545.9483 Department of Physics fax: 413.545.4884 Univ. of Massachusetts AIM: (available upon request) Amherst, MA 01003-9337 USA http://umperg.physics.umass.edu/ -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- ___ 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 )
[Zope-dev] Re: [Zope3-dev] Re: Zope and zope
On Wednesday 14 April 2004 11:08, Jim Fulton wrote: > I want to solve the problem of having both "zope" and "Zope". Great! I would very much prefer a solution like that. > > I really > > hope that will not be the case. > > Why? I was referring to renaming "zope" to "zope3" or similar. > > I would hate to have imports like "z3.app.foo" or even "z3.i18n". > > Why? Because in general I don't like version numbers in the path. I also think that "zope" is the only name that is 100% right on. Everything else is a compromise I would try to avoid. We will be sorry about it later, when many more people run Zope 3 only applications. > What about "z.app.foo" or "z.i18n"? The shortness of this example is very attractive, but it is still a compromise in my opinion. Again, I think educating is easier than anything else. People understand that this is due to a merge of codebases and is for a transition period only. And, the TTW scripter will not care. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ 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 )
[Zope-dev] Re: [Zope3-dev] Re: Zope and zope
Chris McDonough wrote: Note that the reason I suggested renaming Zope to "zope2" (or whatever) as opposed to "zope" to "zope3" is because Zope 3 uses absolute imports almost everywhere; it would be far less work to change "Zope" to "Zope2" because Zope 2 either uses relative imports or assumes it can find what it needs on sys.path. Zope 3 is still (for a short time) in a far more plastic state. There aren't many third-party products and their authors expect change at this time. For example, we very recently rearranged the zope.app package. > I think the breakage, although literally "incalculable" (as is every change to Zope 2, given that it has no canonical API), would be manageable given enough lead time. In fact, if we did change the module name, we could just leave a "bruce" package in place that, when imported, raised a "ObsoleteError" with a descriptive message. But I think that this is a big problem. Backward compatibility for Z2 *is* important. It's too bad that lots of test files have to import Zope. Sigh. I *hate* the idea of having two packages named "zope" where case is the only thing different. Me too, the more I think about it. > It's would be insanely difficult (not to mention embarrassing) to document, should the two codebases merge in some unholy fashion at some point as is on the 2.9 roadmap. Actually, the Zope 2.8 roadmap. :) Zope 2.8 will have Zope 3 interfaces. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ 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 )
[Zope-dev] Re: [Zope3-dev] Re: Zope and zope
Stephan Richter wrote: On Tuesday 13 April 2004 22:17, Tres Seaver wrote: Of course, having two packages with names differing only in case is a bit ugly. Do we want to consider renaming one or both of these packages to avoid the conflict? -1 to renaming 'Zope'; the amount of third-party code which we would break is incalculable. -0 to renaming 'zope' to 'z3', or something; at least third party code for Zope3 was built in the test-driven culture, and has at least some chance of migrating cleanly with confidence. You wanna rename 'zope' to 'z3' Tres doesn't. I want to solve the problem of having both "zope" and "Zope". > for the purpose of merging the two? Yes > I really hope that will not be the case. Why? > Or is this for Zope 2 only? No, it would have to apply to both. Packages that would otherwise work with Zope 3 in Zope 2 should not have to be changed to be used with Zope 3. I would hate to have imports like "z3.app.foo" or even "z3.i18n". Why? What about "z.app.foo" or "z.i18n"? Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ 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 )
[Zope-dev] Re: [Zope3-dev] Zope and zope
Jim Fulton wrote: ... Give the responses. I need to recast my question as a selection among alternatives. But, before I do that, we will need to consider alternatives a bit more. OK, here's another. What about renaming the Zope 3 zope package to "z". - It fits with the expansion of "Zope": "Z Object Publishing Environment". - It's short :) - *At this time* (but after the move to svn), it's not too hard to make a change like this for Zope 3. Backward compatibility is not a big issue. This will change when X3.0 is released, which is why I'm bothering to deal with this now. - This was suggested a couple of years ago when coming up with the Zope 3 package layout. Examples (from the buddydemo example): import z.interface from z.app import zapi from z.app.event import publish from z.app.event.objectevent import ObjectModifiedEvent Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ 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 )
Re: [Zope-dev] Re: [Zope3-dev] Zope and zope
Jim Fulton wrote: The first question is: Is it a problem to have two packages with names differing only in case? +1 A response with a positive sign (e.g. +1, +0, +2, ...) indicates agreement that this is a probelm. :) Jim Andrew -- Zope Corporation Software Engineer (540) 361-1700 ___ 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 )
[Zope-dev] Re: [Zope3-dev] Zope and zope
Jim Fulton wrote: Jim Fulton wrote: ... I should have been clearer. The first question is: Is it a problem to have two packages with names differing only in case? I haven't gotten as many responses on this as I expected. I'll try to summarize Wrong. People don't find the question useful. Give the responses. I need to recast my question as a selection among alternatives. But, before I do that, we will need to consider alternatives a bit more. - Chris feels strongly that this is a problem - I've been swayed by Chris' response from neutral to thinking that this is a problem. In talking about this with Casey, Fred and Barry here, we thought of another problem with the status quo. The standard Python library has a module, pkgutil that facilitates spreading container packages like zope over multiple directories on the Python path. Thia facilitates installing zope-project packages in different places. Without this, container packages become very unsttractive. It turns out that pkgutil will be confused by the Zope package on Windows or Mac OS, adding it's directory to the zope package's path. This is a bug in pkgutil that can be fixed, but it is an example of the sorts of problems we can expect. In addition, haveing two packages with the same name makes it hard to talk about them verbally. One has to qualify the names, as in "big zope" or "little zope". Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ 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 )
Re: [Zope3-dev] Re: [Zope-dev] zLOG is dead
--On Mittwoch, 14. April 2004 16:45 Uhr +0200 Andreas Jung <[EMAIL PROTECTED]> wrote: --On Mittwoch, 14. April 2004 10:57 Uhr +0200 Lennart Regebro <[EMAIL PROTECTED]> wrote: From: "Andreas Jung" <[EMAIL PROTECTED]> When I look through the Zope HEAD code then you are using e.g. 'zodb.conn' or 'zodb.storage' but also 'Zope' as loggername. Do we have to agree on some common usage of the logger names? E.g. for logging calls in the reST packagebetter using 'Zope' or 'reST'? 'reST' I guess is the onbious one. I would like to see something like this: For Zope core core: Zope.subsystem. i.e. 'Zope.Accesscontrol', 'Zope.OFS'. +1 For the default lib/python/Product stuff: Either Zope.Product or just Product, ie 'MailHost' or 'Zope.MailHost'. Which I don't care, makes no matter for me, but consistency would be good. For consitency: Zope.Products. For lazy writers: Zope. X I prefer the second solution...everyone should know what are products and what are packages. In fact the name does not matter because you can see in the traceback where the error occurs. You don't get this information from the name directly. Of course this applies only if you have an error :-) Anywaynames should be kept as short as possible. -aj ___ 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 )
Re: [Zope-dev] zLOG is dead
--On Mittwoch, 14. April 2004 10:57 Uhr +0200 Lennart Regebro <[EMAIL PROTECTED]> wrote: From: "Andreas Jung" <[EMAIL PROTECTED]> When I look through the Zope HEAD code then you are using e.g. 'zodb.conn' or 'zodb.storage' but also 'Zope' as loggername. Do we have to agree on some common usage of the logger names? E.g. for logging calls in the reST packagebetter using 'Zope' or 'reST'? 'reST' I guess is the onbious one. I would like to see something like this: For Zope core core: Zope.subsystem. i.e. 'Zope.Accesscontrol', 'Zope.OFS'. +1 For the default lib/python/Product stuff: Either Zope.Product or just Product, ie 'MailHost' or 'Zope.MailHost'. Which I don't care, makes no matter for me, but consistency would be good. For consitency: Zope.Products. For lazy writers: Zope. X I prefer the second solution...everyone should know what are products and what are packages. In fact the name does not matter because you can see in the traceback where the error occurs. You don't get this information from the name directly. For other Products: Just the product name. In the case of CMF and CPS and other things, you could possibly decide to use 'CMF.Core' and 'CMF.Default' instead of 'CMFCore' and 'CMFDefault' by that also seems kinda silly. Keep the product name as it is...means Products/ should use Zope. as logger name. No need to introduce a new mapping. Keep it simple. -aj ___ 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 )
RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely r evis ion based storage for Zope ?)
The property schema thing is a good point, though I'm not sure we could ever do anything about it, not with the purpose to help "naive gui" clients work better with the repository. By nature the object structure (Class instance) is not fixed, so the amount/name/data of properties could vary arbitrarily. This is after all the major benefit of an OODBMS. Fact is if one wanted a client to interact with a svn repository that stores zope objects, it would need to be fairly specifically designed for it ... How would a client (Say dreamweaver with a subversion plug-in) know that when editing an image, the x and y size properties need to be updated ? What if someone monkey patches the image type to add some other property/attribute ? All we could hope to do is find a consistent and predictable way to handle properties, so that clients would know at the very least how to read/write them, but not necessarily know which one does what. I suppose there's possible ways around that actually, by providing some way to describe properties and what they do and so on ... but that's beyond the scope of what I'm trying to do I think ... J.F. -Original Message- From: Kapil Thangavelu [mailto:[EMAIL PROTECTED] Sent: April 14, 2004 6:51 AM To: Shane Hathaway Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely r evis ion based storage for Zope ?) On Tue, 2004-04-13 at 22:46, Shane Hathaway wrote: > On Tue, 13 Apr 2004 [EMAIL PROTECTED] wrote: > > > Thanks for the extra tips, I'll check out those interfaces! I'm also getting > > up to speed on the whole mapper concept, where the work regarding properties > > handling seems to be ? > > Ape supports both annotations and Zope properties. Annotations are blocks > of multi-line text, while Zope properties are less constrained. On the > filesystem, Ape stores many Zope properties together in a single > annotation called "properties". Other annotations include object > classification, the remainder pickle (encoded in base 64), and security > information. > > What are the expectations and limits of Subversion properties? If they > are blocks of multi-line text, you can store the annotations as Subversion > properties. If not, we'll still need a .properties file. (Note that > the name ".properties" is thus confusing. Oops.) > svn supports aribtrary property values. ie you can store binary (remainder pickles, object classification, etc.) of arbitrary size on them. there is some question of how well some naive gui client will do when trying to list such properties, as there is currently no notion of metaproperties/property schema beyond the property namespace for introspection of a property. -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 )
RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely r evis ion based storage for Zope ?)
Well there you go, perfect :) -Original Message- From: Kapil Thangavelu [mailto:[EMAIL PROTECTED] Sent: April 14, 2004 6:49 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely r evis ion based storage for Zope ?) On Tue, 2004-04-13 at 20:53, [EMAIL PROTECTED] wrote: > Hello, > > Hmmm, well it's as stable as Ape and Subversion are respectively :) > > I wouldn't call it stable no, it's something I did over the long week-end we > just had, and that's about it :) > > Ape is at 0.8 and therefore becoming quite mature, I'd have to let others > speak as to it stability however ... > > Subversion is also probably quite stable (It just reached 1.0), though I > don't know how heavily tested it's been in a long running process (Might it > have some memeory leaks ?) ... the svn apache server model is a long running process and is fairly stable on memory usage. the python bindings require doing some manual memory management, but the pool api makes it easy to deallocate arbitrary allocations safely. the cmfsvnbrowser code i ref'd early has been in production by myself and others for almost a year and runs with a stable memory footprint. -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 )
RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely r evis ion based storage for Zope ?)
Shane, As Kapil already mentionned, svn's support for properties is quite flexible, so that doesn't worry me too much. I would imagine and administrator having the flexibility of choosing how objects get translateds to files might be handy. 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 ? 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. 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. The benefits I see: - The filesystem reflects the object structure, no extra files lying around. - 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". - with the use of the properties related svn funtions, we better leverage SVN's features. - possibly better performance/simpler code by not needing the whole multiple file management and read/write of text files. Heck the whole AnnotatedFileSystem, thing could be dropped/replaced with a PropertyFileSystem implementation of some kind maybe ?? What do you think ? J.F. -Original Message- From: Shane Hathaway [mailto:[EMAIL PROTECTED] Sent: April 13, 2004 10:46 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely r evis ion based storage for Zope ?) On Tue, 13 Apr 2004 [EMAIL PROTECTED] wrote: > Thanks for the extra tips, I'll check out those interfaces! I'm also getting > up to speed on the whole mapper concept, where the work regarding properties > handling seems to be ? Ape supports both annotations and Zope properties. Annotations are blocks of multi-line text, while Zope properties are less constrained. On the filesystem, Ape stores many Zope properties together in a single annotation called "properties". Other annotations include object classification, the remainder pickle (encoded in base 64), and security information. What are the expectations and limits of Subversion properties? If they are blocks of multi-line text, you can store the annotations as Subversion properties. If not, we'll still need a .properties file. (Note that the name ".properties" is thus confusing. Oops.) > As for the seperation of code ... I now have a "subversion" directory as a > sibbling to "fs" ... I had to edit a couple of files outside that directory, > but still the seperation is nicer. > > eventually I'd have to make it into a product, is that doable ? Why not add your code to Ape? I think it would be easier for both of us to maintain that way. Shane ___ 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 )
[Zope-dev] Re: Zope and zope
Philipp von Weitershausen wrote: Jim Fulton wrote: The first question is: Is it a problem to have two packages with names differing only in case? I don't see a problem at all; IIRC, we agreed that the backports from Zope3 would live in a 'src' directory, while Zope 2 stuff continues to live in 'lib/python'. No case problem therefore, since they would be in different directories. As I mentioned in my note, Python allows us to have two packages whos names differ only by case. I also noted that this requires adding an additional directory to the path. This isn't a big deal. I think it's an annoyance. I haven't gotten as many responses on this as I expected. I'll try to summarize so far: - Chris feels strongly that this is a problem - I've been swayed by Chris' response from neutral to thinking that this is a problem. - Tres seems not to think this is a problem, but I'm not sure. - Fred doesn't seem to think this is a problem. - I can't tell from Robert's and Stephans responses whether they think this is a problem or not. Perhaps we can get more input on whether there's a problem. A response with a positive sign (e.g. +1, +0, +2, ...) indicates agreement that this is a probelm. :) -2 Wow. That's a strong opinion that there's no problem :) especially since: ... I can see why it might be embarrassing having to document two package names that only differ by case. For newbies, it might even be confusing This sounds like an argument for there being a problem. I guess your large negative vote is a vote against the alternatives... fair enough. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ 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 )
[Zope-dev] Re: [Zope3-dev] Zope and zope
-1, it is not really a problem. As Chris pointed out, this will be hard to explain in documentation, but I think it will not be as big of a pain as requiring 3rd parties to change their code (this is for both, Zope 2 and 3). Furthermore, I really dislike the option of renaming "zope" in Zope 3 to something else. If you have a directory structure like lib/python Zope zope3/zope where both, 'lib/python' and 'lib/python/zope3' are in the path, then this is pretty obvious. I think that only advanced Zope 2.8+ programmers will want to use both Zope 2 and 3 functionality, so that educating them about this is much easier than educating the scripter. Regards, Stephan On Wednesday 14 April 2004 09:00, Jim Fulton wrote: > Jim Fulton wrote: > > Zope 2 has a package named "Zope". Zope 3 has a package named "zope". > > Starting with Zope 2.8, parts of Zope 3 will be included in Zope 2. > > As things stand, this will require having both "Zope" and "zope" > > packages. Python can handle this fine, however, it will require putting > > the packages in separate directories (for Windows). A typical Zope > > installation will probably add at least two directories to the Python > > path, for: > > > > - The Zope software > > > > - Instance (site) specific packages > > > > So adding two directories, rather than one for the Zope software isn't > > a big deal. > > > > Of course, having two packages with names differing only in case is a > > bit ugly. > > > > Do we want to consider renaming one or both of these packages > > to avoid the conflict? > > I should have been clearer. > > The first question is: > > Is it a problem to have two packages with names differing only in case? > > I haven't gotten as many responses on this as I expected. I'll try to > summarize so far: > > - Chris feels strongly that this is a problem > > - I've been swayed by Chris' response from neutral to thinking that this >is a problem. > > - Tres seems not to think this is a problem, but I'm not sure. > > - Fred doesn't seem to think this is a problem. > > - I can't tell from Robert's and Stephans responses whether they think this >is a problem or not. > > Perhaps we can get more input on whether there's a problem. > > A response with a positive sign (e.g. +1, +0, +2, ...) indicates > agreement that this is a probelm. :) > > Jim -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ 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 )
Re: [Zope-dev] Re: [Zope3-dev] Zope and zope
On Wednesday 14 April 2004 09:54 am, Kapil Thangavelu wrote: > its probably a problem imo for mac users who are on a case insensitive > fs. Is this still an issue for Mac OS X, or is your concern for classic Mac OS? I don't know if we support that (simply because I've never heard anyone mention it). > none of the alternative seem all that appealing though.. the comment No, they don't. The current Zope 3 naming for modules and packages mostly follows the current BDFL recommendations, which is nice, and is friendly to to those of use alergic to upper case letters. It also works well for case-senseless filesystems. > about most z3 imports being prefixed with zope, suggests that any > backwards porting with a goal of forward compatibility will require > changing the existing z2 Zope package to something else, although > sticking version numbers on package names doesn't hold much appeal for > me. perhaps renaming z2 Zope->Core The Zope 2 "Zope" package is actually quite small. Perhaps renaming it is the best approach. In spite of Tres's objection, I don't see how there could be all that much code that references it. Perhaps it's referenced by some persistent objects? There's an uncertain comment in Zope.ClassFactory, and Zope.App.ClassFactory might be referenced, but otherwise the Zope package contains startup code. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation ___ 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 )
[Zope-dev] Re: Zope and zope
Jim Fulton wrote: The first question is: Is it a problem to have two packages with names differing only in case? I don't see a problem at all; IIRC, we agreed that the backports from Zope3 would live in a 'src' directory, while Zope 2 stuff continues to live in 'lib/python'. No case problem therefore, since they would be in different directories. I haven't gotten as many responses on this as I expected. I'll try to summarize so far: - Chris feels strongly that this is a problem - I've been swayed by Chris' response from neutral to thinking that this is a problem. - Tres seems not to think this is a problem, but I'm not sure. - Fred doesn't seem to think this is a problem. - I can't tell from Robert's and Stephans responses whether they think this is a problem or not. Perhaps we can get more input on whether there's a problem. A response with a positive sign (e.g. +1, +0, +2, ...) indicates agreement that this is a probelm. :) -2 The reason why I don't see a big problem from the aesthetic point of view is that the 'Zope' package isn't used much in Zope2 anyway. Most stuff is in top-level packages such as OFS, App, Acquisition, ZPublisher, ZServer etc. I have Zope2 products that don't even import from 'Zope'. So, who would care? Renaming it would just be a hassle and asking for trouble (esp. regarding incompatabilies). I can see why it might be embarrassing having to document two package names that only differ by case. For newbies, it might even be confusing (though again, who ever gets in touch with lib/python/Zope?). But so is Zope2's codebase already. Most code is icky and naming conventions simply don't exist. Philipp ___ 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 )
Re: [Zope-dev] Re: [Zope3-dev] Zope and zope
Kapil Thangavelu wrote: On Wed, 2004-04-14 at 09:00, Jim Fulton wrote: The first question is: Is it a problem to have two packages with names differing only in case? Perhaps we can get more input on whether there's a problem. A response with a positive sign (e.g. +1, +0, +2, ...) indicates agreement that this is a probelm. :) +1 its probably a problem imo for mac users who are on a case insensitive fs. none of the alternative seem all that appealing though.. Thanks for the input. I'd prefer to defer discussion on alternatives until we determine whether there is a problem we want to fix. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ 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 )
RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely r evis ion based storage for Zope ?)
Kapil, Right now, the svn transactions are entirely contained within a single fileops operation: for example a "mkdir" connects to a transaction root, performs the necessary operations, and commits, all in one shot. Last night I took some more time to try and learn more about Ape's functionning (Where events come from, which interfaces are used for what, and TPC), so I'm starting to understand more ... The more I learn, the more I think closer integration between SVN txn's and Ape's TPC would be a good place to start before looking at adding features like history support and so on: defining a model for what happens in svn for each TPC related call (connect, vote, finish), and then as Shane had said, look at IFSReader/IFSWriter (Which I now call ISubversionReader/ISubversionWriter :P) to match. Right now the fs implementation stores "script commands" that are cummulated upon connect() (I think?), validated as best as possible upon vote() and run upon finish(). I don't see why this couldn't be adapted to SVN txn's ... connect() = start a txn, vote() = validation (what this entails needs to be defined, could involve delta operations, revision number matching, etc ... ?), finish() = commit the svn txn. Because we're within an svn transaction, there would be no need for fs style script command accumulation however, which is nice. J.F. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Kapil Thangavelu Sent: April 14, 2004 6:59 AM To: Shane Hathaway Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely revis ion based storage for Zope ?) On Tue, 2004-04-13 at 12:01, Shane Hathaway wrote: > On Tue, 13 Apr 2004, Kapil Thangavelu wrote: > > > since > > objects modified in a version are in essence locked from participating > > in other transactions, actions like modifying content in a version in a > > cmf site amounts to locking the catalog from changes outside of the > > version, which amounts to shutting down write activities to a cmf site. > > This is only true of FileStorage. Some other storage could implement ZODB > versions with merging capability rather than locking. > good point, just because hasn't been doesn't mean it can't ;-) although i wonder if there is some hand waving in progress here that i can't see. i guess my semantic notion of versions has been that of long lived transactions, and is there a better means of thinking of them? how do they play across with multiple mounted zodbs? what would something like merge mean in the context of a catalog? > > i'm also curious how you dealt with svn transactions as part of the ape > > integration work to date. > > The same way it tries to impose transactions on the filesystem: in the > vote phase, Ape looks for possible problems and aborts early if it detects > anything that will cause the transaction to fail. Obviously, this > provides no guarantee, but covers many cases. > i was more curious how jean-francois was doing the svn ops in fileops, as svn is fundamentally a transactional store (as opposed to the fs), ie is there some record boundary notion of ape signalling the end of serialization for an object set, or was each operation being conducted in a separate svn transaction. -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 ) ___ 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 )
[Zope-dev] Re: Zope + Ape + Subversion (was: RE: Using a truely revis ion based storage for Zope ?)
On Wed, 14 Apr 2004 09:50:17 -0400 Casey Duncan <[EMAIL PROTECTED]> wrote: [..] > In practical terms this would mean that the versioned catalog would > need to keep track of the uids that had been cataloged, uncataloged > and reindexed in the version. The "merge" would mean cataloging, > uncataloging and reindexing those same uids in the current catalog. A complicating factor to this though is that it would need to be done *after* all of the other content merges. That implies some sort of dependancy graph, *bleah*. I've never been terribly fond of the idea of catalogs as top-level instance space objects (i.e., peers to the content they catalog), and things like this are one of the reasons why. In any case it might be good enough for an object to be able to say "merge me last". Other toolsy and servicey sorts of objects that depend on content (like a workflow state repository) might want to do so as well. As long as the state of the tools doesn't depend on each other, then it's ok. That last sentence is making me a little ill, however ;^) -Casey ___ 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 )
[Zope-dev] Re: Zope and zope
+1 this is a problem. The question is whether curing it is *more* of a problem. -Casey On Wed, 14 Apr 2004 09:00:26 -0400 Jim Fulton <[EMAIL PROTECTED]> wrote: > Jim Fulton wrote: > > > > Zope 2 has a package named "Zope". Zope 3 has a package named > > "zope". Starting with Zope 2.8, parts of Zope 3 will be included in > > Zope 2. As things stand, this will require having both "Zope" and > > "zope" packages. Python can handle this fine, however, it will > > require putting the packages in separate directories (for Windows). > > A typical Zope installation will probably add at least two > > directories to the Python path, for: > > > > - The Zope software > > > > - Instance (site) specific packages > > > > So adding two directories, rather than one for the Zope software > > isn't a big deal. > > > > Of course, having two packages with names differing only in case is > > a bit ugly. > > > > Do we want to consider renaming one or both of these packages > > to avoid the conflict? > > I should have been clearer. > > The first question is: > > Is it a problem to have two packages with names differing only in > case? > > I haven't gotten as many responses on this as I expected. I'll try to > summarize so far: > > - Chris feels strongly that this is a problem > > - I've been swayed by Chris' response from neutral to thinking that > this >is a problem. > > - Tres seems not to think this is a problem, but I'm not sure. > > - Fred doesn't seem to think this is a problem. > > - I can't tell from Robert's and Stephans responses whether they think > this >is a problem or not. > > Perhaps we can get more input on whether there's a problem. > > A response with a positive sign (e.g. +1, +0, +2, ...) indicates > agreement that this is a probelm. :) > > Jim > > -- > Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! > CTO (540) 361-1714http://www.python.org > Zope Corporation http://www.zope.com http://www.zope.org ___ 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 )
Re: [Zope-dev] Re: [Zope3-dev] Zope and zope
On Wed, 2004-04-14 at 09:00, Jim Fulton wrote: > The first question is: > > Is it a problem to have two packages with names differing only in case? > > > Perhaps we can get more input on whether there's a problem. > > A response with a positive sign (e.g. +1, +0, +2, ...) indicates > agreement that this is a probelm. :) +1 its probably a problem imo for mac users who are on a case insensitive fs. none of the alternative seem all that appealing though.. the comment about most z3 imports being prefixed with zope, suggests that any backwards porting with a goal of forward compatibility will require changing the existing z2 Zope package to something else, although sticking version numbers on package names doesn't hold much appeal for me. perhaps renaming z2 Zope->Core -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 )
[Zope-dev] Re: Zope + Ape + Subversion (was: RE: Using a truely revis ion based storage for Zope ?)
On Wed, 14 Apr 2004 06:59:05 -0400 Kapil Thangavelu <[EMAIL PROTECTED]> wrote: > On Tue, 2004-04-13 at 12:01, Shane Hathaway wrote: > > On Tue, 13 Apr 2004, Kapil Thangavelu wrote: > > > > > since > > > objects modified in a version are in essence locked from > > > participating in other transactions, actions like modifying > > > content in a version in a cmf site amounts to locking the catalog > > > from changes outside of the version, which amounts to shutting > > > down write activities to a cmf site. > > > > This is only true of FileStorage. Some other storage could > > implement ZODB versions with merging capability rather than locking. > > > > good point, just because hasn't been doesn't mean it can't ;-) > > although i wonder if there is some hand waving in progress here that i > can't see. i guess my semantic notion of versions has been that of > long lived transactions, and is there a better means of thinking of > them? how do they play across with multiple mounted zodbs? what would > something like merge mean in the context of a catalog? Catalogs are actually fairly easy to handle, at least in theory. The state of the catalog directly depends (and is derived from) the current state of the cataloged objects. So merging the catalog should mean: merge the content first and then reindex it. >From this pov, it would be possible to get cataloging right in the current version machinery as well. This machinery would need to allow objects to override the locking behavior in some way. In the case of the catalog it would be fine for a current catalog and the one in the version to ignore each other (i.e., changing the one in the version does not lock the current one). Then when the version is saved/merged, the affected objects are recataloged. In practical terms this would mean that the versioned catalog would need to keep track of the uids that had been cataloged, uncataloged and reindexed in the version. The "merge" would mean cataloging, uncataloging and reindexing those same uids in the current catalog. -Casey ___ 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 )
[Zope-dev] Re: [Zope3-dev] Zope and zope
Jim Fulton wrote: Zope 2 has a package named "Zope". Zope 3 has a package named "zope". Starting with Zope 2.8, parts of Zope 3 will be included in Zope 2. As things stand, this will require having both "Zope" and "zope" packages. Python can handle this fine, however, it will require putting the packages in separate directories (for Windows). A typical Zope installation will probably add at least two directories to the Python path, for: - The Zope software - Instance (site) specific packages So adding two directories, rather than one for the Zope software isn't a big deal. Of course, having two packages with names differing only in case is a bit ugly. Do we want to consider renaming one or both of these packages to avoid the conflict? I should have been clearer. The first question is: Is it a problem to have two packages with names differing only in case? I haven't gotten as many responses on this as I expected. I'll try to summarize so far: - Chris feels strongly that this is a problem - I've been swayed by Chris' response from neutral to thinking that this is a problem. - Tres seems not to think this is a problem, but I'm not sure. - Fred doesn't seem to think this is a problem. - I can't tell from Robert's and Stephans responses whether they think this is a problem or not. Perhaps we can get more input on whether there's a problem. A response with a positive sign (e.g. +1, +0, +2, ...) indicates agreement that this is a probelm. :) Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ 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 )
Re: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely revis ion based storage for Zope ?)
granted the svn integration has lots of coolness factors including richer client integration, but things like zope version control (zope.org cvs) are already production quality and not so hard to integrate in for basic version control. -kapil On Tue, 2004-04-13 at 14:13, Arthur Chan Chi Chuen wrote: > Hi all, > > I've read your discussion about version control, it seems a cool thing you > guys making good progress. Btw, can I ask is the Ape using Subversion in Zope > stable? how able CMF stuff? I wanna make/find a document management system > which can provide some kinda version control in Plone. > > Thanks > Arthur > On Tue, 13 Apr 2004 04:06:26 -0400, Kapil Thangavelu wrote > > On Mon, 2004-04-12 at 18:03, [EMAIL PROTECTED] wrote: > > > G'Day, > > > > > > Well, step one is done ... I now have Zope + Ape using Subversion as it's > > > "filesystem" !! > > > > > > > cool! > > > > > This is step one because, as Shawn suggested (Thanks for the pointer, > that's > > > what I needed!), this simply means that Zope uses SVN purely as a > > > filesystem. > > > > > > > > Because of subversion's nature, I want to look at 2 things beyond this > that > > > traditional filesystems don't support: > > > > > > - Use zope's username for SVN logging. > > > > using AccessControl.getSecurityManager().getUser().getId() and > > setting it up as a revision prop ( or directly when creating the > > repo transaction) should do it. > > > > > - History/Undo support: View past revisions of an object, and revert to > such > > > a past revision. > > > > perhaps the code for this would be helpful, (remove image for code > > link) > http://zope.org/Members/k_vertigo/Products/CMFSubversionBrowser/FileRevisions. > png > > > > > - Zope Version support: SVN is fully transactional and atomic, this should > > > allow for support of Zope versions (I think ?) > > > > > > > zope version support isn't really all that worthwhile, esp in a cmf > > context. in general zope's version support (or zodb more > > particularly) is a database level feature masquerading as an > > application one. since objects modified in a version are in essence > > locked from participating in other transactions, actions like > > modifying content in a version in a cmf site amounts to locking the > > catalog from changes outside of the version, which amounts to > > shutting down write activities to a cmf site. otoh, integration with > > zope's transaction manager would be a good thing, although its > > problematic to integrate between svn and zope txn models, more on > > that in a moment. > > > > > In the longer term, there's great opportunity for: > > > > > > - "Built-in" conflict management and resolution: No more need for a > > > "SafetyBelt" type approach. Right now I haven't looked at this at all. I > > > plan to implement smart merging where possible (It might work already > > > actually, I just need to test it). True conflicts (Where a merge can't be > > > accomplished withouth user interaction) would raise some sort of conflict > > > error. > > > > > > > i don't know that conflict management is really useful in this context. > > svn like zope relies on optimistic concurrency control, and currently > > doesn't support dav locking (which zope does). ie, it will just > > throw an error if the content has been changed since the transaction > > began. the 'normal' concurrency control of svn is better but > > dependent on using the working copy (wc) layer, which is additional > > programming and storage overhead. so at the layer of the svn client > > this is already done and working and good, but integrating this > > functionality into zope is a bit harder without wc overhard. > > > > this also makes the transaction integration becomes harder because both > > zope and svn are using what amounts to optimistic concurrency control > > which makes it impossible afaics, to get real txn integration, ie in > > zope's two phase commit strategy, the last chance for a participant > > to safely abort is tpc_vote, but there is no real way of knowing if > > the svn txn will suceed or not until its tried. if it is tried at > > this stage and succeeds then there is the possibility of a latter > > txn participant failing the tpc_vote and the txn being aborted, and > > if waits till tpc_finish (last part of two phase commit) and the svn > > txn fails it can hose the composite txn integrity. > > > > once svn supports dav locks, doing txn integration via resource locking > > as part of tpc_vote (or earlier) would be possible, till then.. i > > dunno, i can't see a way around this for real txn integration. > > > > i'm also curious how you dealt with svn transactions as part of the ape > > integration work to date. > > > > > - Editing Zope content objects through interaction with the svn > repository. > > > I can checkout the repository, edit some objects, and chek them back in, > > > never interacting with Zope directly ... I've alread
Re: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely revis ion based storage for Zope ?)
On Tue, 2004-04-13 at 12:01, Shane Hathaway wrote: > On Tue, 13 Apr 2004, Kapil Thangavelu wrote: > > > since > > objects modified in a version are in essence locked from participating > > in other transactions, actions like modifying content in a version in a > > cmf site amounts to locking the catalog from changes outside of the > > version, which amounts to shutting down write activities to a cmf site. > > This is only true of FileStorage. Some other storage could implement ZODB > versions with merging capability rather than locking. > good point, just because hasn't been doesn't mean it can't ;-) although i wonder if there is some hand waving in progress here that i can't see. i guess my semantic notion of versions has been that of long lived transactions, and is there a better means of thinking of them? how do they play across with multiple mounted zodbs? what would something like merge mean in the context of a catalog? > > i'm also curious how you dealt with svn transactions as part of the ape > > integration work to date. > > The same way it tries to impose transactions on the filesystem: in the > vote phase, Ape looks for possible problems and aborts early if it detects > anything that will cause the transaction to fail. Obviously, this > provides no guarantee, but covers many cases. > i was more curious how jean-francois was doing the svn ops in fileops, as svn is fundamentally a transactional store (as opposed to the fs), ie is there some record boundary notion of ape signalling the end of serialization for an object set, or was each operation being conducted in a separate svn transaction. -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 )
RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely r evis ion based storage for Zope ?)
On Tue, 2004-04-13 at 22:46, Shane Hathaway wrote: > On Tue, 13 Apr 2004 [EMAIL PROTECTED] wrote: > > > Thanks for the extra tips, I'll check out those interfaces! I'm also getting > > up to speed on the whole mapper concept, where the work regarding properties > > handling seems to be ? > > Ape supports both annotations and Zope properties. Annotations are blocks > of multi-line text, while Zope properties are less constrained. On the > filesystem, Ape stores many Zope properties together in a single > annotation called "properties". Other annotations include object > classification, the remainder pickle (encoded in base 64), and security > information. > > What are the expectations and limits of Subversion properties? If they > are blocks of multi-line text, you can store the annotations as Subversion > properties. If not, we'll still need a .properties file. (Note that > the name ".properties" is thus confusing. Oops.) > svn supports aribtrary property values. ie you can store binary (remainder pickles, object classification, etc.) of arbitrary size on them. there is some question of how well some naive gui client will do when trying to list such properties, as there is currently no notion of metaproperties/property schema beyond the property namespace for introspection of a property. -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 )
RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely r evis ion based storage for Zope ?)
On Tue, 2004-04-13 at 20:53, [EMAIL PROTECTED] wrote: > Hello, > > Hmmm, well it's as stable as Ape and Subversion are respectively :) > > I wouldn't call it stable no, it's something I did over the long week-end we > just had, and that's about it :) > > Ape is at 0.8 and therefore becoming quite mature, I'd have to let others > speak as to it stability however ... > > Subversion is also probably quite stable (It just reached 1.0), though I > don't know how heavily tested it's been in a long running process (Might it > have some memeory leaks ?) ... the svn apache server model is a long running process and is fairly stable on memory usage. the python bindings require doing some manual memory management, but the pool api makes it easy to deallocate arbitrary allocations safely. the cmfsvnbrowser code i ref'd early has been in production by myself and others for almost a year and runs with a stable memory footprint. -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 )
Re: [Zope-dev] zLOG is dead
From: "Andreas Jung" <[EMAIL PROTECTED]> > When I look through the Zope HEAD code then you are using e.g. > 'zodb.conn' or 'zodb.storage' but also 'Zope' as loggername. Do we > have to agree on some common usage of the logger names? > E.g. for logging calls in the reST packagebetter using 'Zope' or 'reST'? 'reST' I guess is the onbious one. I would like to see something like this: For Zope core core: Zope.subsystem. i.e. 'Zope.Accesscontrol', 'Zope.OFS'. For the default lib/python/Product stuff: Either Zope.Product or just Product, ie 'MailHost' or 'Zope.MailHost'. Which I don't care, makes no matter for me, but consistency would be good. For other Products: Just the product name. In the case of CMF and CPS and other things, you could possibly decide to use 'CMF.Core' and 'CMF.Default' instead of 'CMFCore' and 'CMFDefault' by that also seems kinda silly. Right? //Lennart ___ 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 )
Re: [Zope-dev] Re: PlacelessTranslationService syntax
I realize that my original post implied that I failed to do the homework. Here's the info: My .po file is OK. Zope 2.7 reads it correctly, as shown in startup log. When I test the translation in /Control_Panel/TranslationService/manage_main, it translates the message 'Good morning' correctly. I've read all docs that I could find. I need this for straight Zope (no CMF, no Plone). -- Milos Prudek ___ 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 )
