- Zope-Dev - Zope lists

Do we need a Packages directory in the new repository
by Jim Fulton 26 Apr '04

26 Apr '04

Historically, we've had Packages, Products, Packages3 and Products3 directories in the CBS repository. I wonder of we need these going forward. Perhaps we should just have top-level projct directories in the new subversion repository. In the initial conversion, I plan to convert projects pretty selectively. Initially, we'll convert only parts needed for Zope 2, Zope 3 and ZODB. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org

3 2

CVS to svn conversion of the heads this Wednesday
by Jim Fulton 25 Apr '04

25 Apr '04

I'd like to plan to convert the repository heads to subversion this Wednesday. I'll confirm this on Tuesday. It will be best of no one does any work on the head on Wednesday. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org

1 0

copypastemove.ObjectMover / Bug
by Roger Ineichen 25 Apr '04

25 Apr '04

package/class: zope.app.copypastemove.ObjectMover I think theres a bug or at least to less checks in the ObjectMover method moveableTo(). example that should raise a Error: The objects in a tree: root/folder2/folder2_2 if I copy folder2 to folder2_2 with: mover = IObjectMover(folder2) # or ObjectMover(folder2) if mover.moveableTo(folder2_2): mover.moveTo(folder2_2) the method moveableTo should return False, otherwise we get a tree like: root/ ..nothing.. /folder2_2/folder2 But the method moveableTo() checks just the constraints. Perhaps we can check if the path of the moveable object is somewhere in the path of the target. Regards Roger Ineichen _____________________________ END OF MESSAGE

1 0

Source Code
by Stephen Corey 24 Apr '04

24 Apr '04

Does anyone have the source code to the Addressit sample program found in the "Zope Bible"? If not all of it, I'm mainly looking for the Addressit.py file. Thanks! __________________________________ Do you Yahoo!? Yahoo! Photos: High-quality 4x6 digital prints for 25� http://photos.yahoo.com/ph/print_splash

1 0

How should an ideal Zope IDE look like?
by kretschmar＠infoman.de 24 Apr '04

24 Apr '04

Hello, it looks as if some people are missing a nice Zope IDE. So I would like to have your oppinions on what an ideal Zope IDE should look like and what technologies it should be built on. Regards, Martin

4 4

New mailing list for ZConfig users
by Fred Drake 23 Apr '04

23 Apr '04

At a suggestion from the community, I've created a new mailing list for ZConfig users. This is for general discussion and questions. The list is run using Mailman at Zope.org; you can sign up at http://mail.zope.org/mailman/listinfo/zconfig/ -Fred -- Fred L. Drake, Jr. <fred at zope.com> PythonLabs at Zope Corporation

1 0

Re: [Zope-dev] [Q] Pickle support for C wrapper and ZEO
by Ames Andreas (MPA/DF) 23 Apr '04

23 Apr '04

Hello Dieter, thanks for your answer. Dieter Maurer <dieter(a)handshake.de> writes: > You mean ZEO client instances not ZEO (server) instances, don't you? Exactly, sorry for having been ambiguous. > Why do you think your ODBC objects should be consistent across > ZEO clients? > I do not think that it is necessary as all your requests your > be independent which means all transactions inside a single > request which implied that connections need not to be shared. The reason why I think about this ZEO scenario is that I thought it was a goal for a ZEO deployment that all ZEO clients behave identical when they respond to the same request. That requires some sort of shared state, which is what ZODB is used for in ZEO, AFAIK. Furthermore such shared state is only useful when the state persist across requests. So I guess my real question should have been: Is it useful/sensible to keep state across request-boundaries within a database adapter in Zope (such state as ODBC-environment, ODBC-connections, ODBC-statements and ODBC-descriptors)? If you don't know ODBC well enough: How do you do it in comparable remote access adapters (for example a CORBA client in Zope or something)? TIA, andreas

2 1

When should one call Connection.sync?
by Syver Enstad 23 Apr '04

23 Apr '04

I am using ZODB 3.2 in a twisted based web application. I have read that I need to call sync to keep the connection up to date. When exactly should I call sync? Are there any drawbacks with calling it immediately after getting a connection, like this: # for each http request. connection = db.open() # (a DB instance) connection.setLocalTransaction() connection.sync() # start using the ZODB here. # if something needs to be committed connection.getTransaction().commit()

2 3

[Q] Pickle support for C wrapper and ZEO
by Ames Andreas (MPA/DF) 22 Apr '04

22 Apr '04

Hi all, I'm reposting here because I had no luck on zope(a)zope.org. I'm in the course of low-level wrapping the ODBC api. Just in case you wonder: I know of mxODBC and pyodbc, they don't fit my needs as well license-wise as technically (I want better metadata access, thread-safety etc.). I'll use my wrapper from within Zope. There will be some python wrapper around the low-level stuff and I wonder if it makes sense to add pickle-support to that python wrapper. The ODBC api is object-based and exhibits four object types: environment, connection, statement and descriptor objects each of which has a set of methods and properties. Pickle-wise I'm not so concerned about persistence across shutdown/restart cycles (I think it's reasonable to re-create your ODBC environments, connections etc. after restart) but rather about consistency across ZEO-instances. My lack of experience makes me ask here for expert advise. 1) Does the ZEO scenario demand some pickle support, e. g. to use consitent environments/connections etc. across ZEO instances or do I just misunderstand ZEO? 2) If pickle support is a good idea: What scope would you find reasonable? I. e. I can imagine that persistence of environments/descriptors could be useful while persistent connections/statements could cause more trouble than they are worth. As you can see the whole thing isn't very clear to me and so I'd appreciate your comments. TIA, andreas

2 1

RE: [Zope-dev] Reflections on the Zope 2 to Zope 3 transition
by Jean-Francois.Doyon＠CCRS.NRCan.gc.ca 22 Apr '04

22 Apr '04

I know I'm new here, but I think this may work to my benefit in this case ... +1 on everything Jim just said! Unlike some others it seems, I look at Zope almost uniquely as "framework" for building web applications. An API or SDK if you will. As such, I think it's internal software desing and architecture has to be priority number one. Otherwise anything you layer on top of it is doomed from the start. To those people that just want an application server that works, such as CPS or Plone, this should still be a very good thing. Having a much higher quality base will mean better end-user usable products in the long run ... Personally, I'm fully expecting to do a full re-design of my code for Zope 3. And that's fine, I like the idea. Given the radical changes in design, I would want to make sure my applications/products take full advantage of the new features. I'm actually counting on several of them to do things like proper multi-lingual support, workflow and publishing control. I might actually NOT bother with migrating slowly through 2.8 and 2.9, that seems dangerous to me ... the potential for kludges and nasty work arounds seems great. We'll have to see. Can't wait for ExtensionClass to go though!! In the mean time, I'll be trying to give back to the Zope community by working on my Subversion storage idea :) Thanks, J.F. -----Original Message----- From: zope-dev-bounces(a)zope.org [mailto:zope-dev-bounces@zope.org]On Behalf Of Jim Fulton Sent: April 22, 2004 10:47 AM To: zope-dev(a)zope.org Cc: zope3-dev(a)zope.org Subject: [Zope-dev] Reflections on the Zope 2 to Zope 3 transition Philipp von Weitershausen wrote: > Jim Fulton wrote: > >>> 2. Especially Andreas expressed his worries about the current release >>> policy in Zope 2 and its future regarding maintainance and support. I >>> have to say that I share some of his skepticism regarding Zope 2. I >>> personally have never fully understood ZC's reasons for the release >>> roadmap as it is. I might not see the big picture, but I know I would >>> have done it differently. I've always tried to make that clear in the >>> past. >> >> >> I'm surprised to read this. Could you be more specific about your >> concerns? > > > I should have said "the release roadmap as it WAS". I was very skeptical > about the original plans to make Zope3 backward compatible. I am still > very skeptical about the ability to add conversion scripts. They would > be incredibly tedious painful to write and I personally would rather > migrate code manually than trust a script. After all, the paradigms have > changed a lot. > > I see it as realistic as Stephan. There is no sane migration to Zope3 > than the one of refactoring code. Now, in order for that to happen, we > need the CA in Zope2, so people can start asap. My only criticism has > been and still is that the CA hasn't been introduced to Zope2 earlier. > Now, I know that a) the CA has been refactored a lot since its invention > (and IMO only for the good) and b) there was a lack of resources to do > that actual integration. That's why I've never declared anyone guilty > for it (which is why you may be surprised by this). > > It sure would have been nice if Gary had shared his experience with > FrankenZope a little earlier. I remember Martijn being quite eager to > experiment with it, too. But that's the only constructive criticism I have. So your concerns are really about the Z2 to Z3 transition plan, not about the Zope release process. Before I get into the main topic of my response, I'll note that I'm a good bit more optimistic about backward compatability than you are. I just have an intuition that we'll be able to do much more than you or Stephan expect. It's an intuition, not a promise. I can't prove it. Only time will tell. :) I know that lots of people are concerned by the uncertainlty about the future transition. This is a tough situation. I made a number of tradeoffs that put us in this situtaion. I think they were the right tradeoffs and I'd make them again. But, as with any tradeoff, we've had to balence positives and negatives. Let me explain: Zope 3 has always been a relatively small project. Within Zope Corporation, I'm the only one that has worked on Zope 3 full time for any length of time. As CTO, even my time on Zope 3 is not truly full time, but it's closer than for anyone else at ZC. Customer work (Zope 2), important community issues (like this thread, or like the security issues we uncovered last fall) take precedent. Other people working on Zope 3 have "day" jobs. They have to go to school or or do customer work (usually in Zope 2) to make a living. (Of course, you know this Philipp. :) I'm not complaining. This is reality and a reality we planned for. I made two choices that were controversial: 1. I decided not to be encumbered by backward compatability. This was refactoring mercelessly" applied in the extreme. This had the result that, except in a few areas, we did start from scratch. Pros: We had freedom to think abstracty about how Zope should work, and how we could make the experience for the developer as good as possible. The premise of not being backward compatible with Zope 2, also made us realize that we didn't have to be backward compatible with our own Zope 3 work. We were free to try things out, see how they worked and often, totally change them to make them better. Many core parts of Zope 3 have been redone, some more than once. This wouldn't have been possible if we had been trying to be backward compatible. Cons: We're not backward compatible. Will we ever be? I'm confident that we will have a decent transition. I don't know what shape that will take but I am still confident. Will there be bumps along the way? Definately. The recent issue with the conflicts between the "Zope" and "zope" package is a good example. While many might not agree with me, I am glad I made this decision. I would make it again. It was the right decision for Zope. If we had a lot more resources, we might have been able to pay more attention to Zope 2 compatability, although I'm not sure that that would have been the right thing to do. 2. I decided not to think much about the transition until Zope 3 has gotten farther along. The transition is a road from where we are to where we're going. It's awfully hard to build a road when the destination is changing. This means that, as the Zope Pope and CTO of Zope Corporation, I can promise that the road will be built, but I can't tell you what precise route the road will take or what it will be like. I can only give a general direction. Frankly, the destination has been well enough defined for a while now that we could begin defining the transition, but we just don't have enough resources to do so. Pros: We didn't waste time planning transition to a moving target. We ere able to focus scarce resources on getting a Zope 3 baseline. Cons: Fear, uncertainty and doubt Do I regret the decision not to define the transition better sooner? No. Not given available resources. I know that this puts the community in a tough spot, but I don't know what else I can do. Fortunately, I think we're pretty close to a time where we can provide a lot more attention to the transition and I think that much more clarity will emerge over coming months. My main regret is so badly underestimating how long it would take to reach where we are. There are a lot of reasons for being so far off. One important reason is that we created a different culture, one that is far more quality driven. We are being very picky about what we put in the Zope 3 baseline. We're willing to take the time to get it right, or at least as right as we can make it. We couldn't do this if it wasn't for Zope 2. Ultimately, I think that this cultural shift will provide us with great benefits. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org _______________________________________________ Zope-Dev maillist - Zope-Dev(a)zope.org 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 )

1 0