March 2006 - Zope-Dev

http access to svn repos?
by Chris Withers 11 Mar '06

11 Mar '06

Hi All, Would anyone be averse to making anonymous http checkouts possible from zope.org? Some of us are behind annoying proxies that won't let svn through :-/ cheers, Chris PS: https write access would be nice, but I guess that's out of the question? -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk

7 16

Redirect Exception and Five
by Santi Camps 07 Mar '06

07 Mar '06

Hi all, I have a problem developing a Product using Five. When a Redirect Exception is raised from a PluggableUserFolder inside my product, it is not handled by the publisher, and I have an error message instead a browser redirect. The same test inside a normal Folder works fine. I'm using Zope 2.9.0, and tried to add this ZCML statements, but I've no luck, and I can't find any other message talking about this. <five:traversable class="OFS.Application.Application"/> <five:traversable class="OFS.Folder.Folder"/> <five:traversable class="zExceptions.Redirect"/> <five:traversable class="Products.PluggableUserFolder.PluggableUserFolder.PluggableUserFolder"/> <five:traversable class=".folder.APWebFolder"/> Anybody knows what could happen ? Thanks -- Santi Camps Earcon S.L. - http://www.earcon.com - http://www.kmkey.com

1 0

Re: [Zope3-dev] Two visions
by Chris McDonough 07 Mar '06

07 Mar '06

On Mar 6, 2006, at 9:21 PM, Jake wrote: > I think it is a huge mistake to lose Zope branding. After years of > building up momentum behind a project, to head off into some > strange developer code speak is just going to lose people who are > not intimately involved. > > The world, after many years, gets versions. Stick to it. > > Works: > Mac OS9 -> Mac OSX (10) > > Here was a mistake: > Mosaic -> Netscape -> Netscape Communicator -> Netscape Gold -> > Firebird -> Mozilla -> Firefox Considering Firefox has nearly 15% marketshare today, I'd call it a success. It certainly could have been worse had Netscape not done the hail mary of releasing it under another name that wasn't conflated with its own brand (witness the takeup rate of Netscape 6/7). - C

1 0

Principles
by Geoff Davis 07 Mar '06

07 Mar '06

I am very glad to see that Jim's efforts to better articulate a vision for Zope have generated so much interest. I am not so sure that the discussion has been an entirely productive one. I think that we as a community would benefit by working on our social engineering as much as our software engineering. There are some straightforward and incredibly effective techniques for helping to ensure that the kinds of discussions we have been having are more productive. The book _Getting To Yes_ ( http://www.amazon.com/gp/product/0140157352 ) does a great job of describing them -- it's required reading in lots of university classes, particularly in MBA programs. The book is nominally about negotiations, but the ideas apply to a huge range of interactions. Here's a summary: http://www.colorado.edu/conflict/peace/example/fish7513.htm One of the things that GTY recommends is to establish a set of agreed upon principles for evaluating proposals. I think that having such a set of principles would help us better focus our current discussion. Let's take a step back from the particulars of the various proposals floating around and see if we can nail down some principles. Here is a very rough, very incomplete start: 1. Zope should have a clear message about where we are going. I'm sure we all agree on this, but this is so broad that it is not very useful. Here's a stab at refining it: 1.1 We should have a clear message about where Zope 2 is going. The message should give existing and prospective Zope 2 users an idea of how long their code will continue to work on releases in the Zope 2 path and what kind of upgrade process they will face as the Zope 2 line evolves. 1.2 Ditto for Zope 3. 2. Zope should try to expand its developer base. Again, I am sure we all agree, but this is too broad to be useful. 2.1 Zope should leverage the work of others by moving toward an architecture that allows one to easily use code from outside Zope. This effectively increases the developer base by letting us leverage the work of others outside the immediate Zope community. I assume that this (and integration) are the primary motivations driving the CA. 2.2 Zope should be useful for developers not using the full application server stack. Again, this serves to increase our developer base by drawing in people outside our traditional core audience. We probably need some principles about the Zope brand, and so on, but I think this should serve as a useful starting point. Let's see if we can expand and refine these principles before going down the "vision" road. I think that we will find that once we have articulated a set of core principles, defining a vision that adheres to them will be much easier. Geoff

3 2

Windows Binary for 2.8.6?
by Chris Withers 07 Mar '06

07 Mar '06

Hi All, I notice 2.8.6 doesn't have a Windows binary either. What's the build process for that? I have a feeling I won't be able to help with that one since it probably need CV++ 6.0 which I don't have access to :-/ Can someone else pick this one up? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk

2 3

Two visions
by Jim Fulton 06 Mar '06

06 Mar '06

I'd like to get feedback on two possible visions for the future of Zope 2 and Zope 3. 1) Our current vision (AFAIK) is that Zope 3 will eventually replace Zope 2 - There will be lots of overlap between the Zope 2 and Zope 3 lifetimes. (Zope 2 might be supported more or less forever.) - Eventually, the gap between Zope 2 and will become very small. requiring a small leap. In this vision, Zope 3 would have to become a lot more like Zope 2, or we would lose features. 2) In an alternate vision, Zope 2 evolves to Zope 5. - Zope 5 will be the application server generally known as Zope. It will be backward compatible (to the same degree that Zope 2 releases are currently backward compatible with previous Zope 2 releases) with Zope 2. Zope 5 will similarly be backward compatible with Zope 3 applications built on top of the current Zope 3 application server. Note that Zope 5 will leverage Zope 3 technologies to allow a variety of configurations, including a Zope 2-like configuration with implicit acquisition and through-the-web development, and a Zope 3-like configuration that looks a lot like the current Zope 3 application server. Maybe, there will be a configuration that allows Zope 2 and Zope 3 applications to be combined to a significant degree. - Zope 3 will explode. :) For many people, Zope 3 is first a collection of technologies that can be assembled into a variety of different applications. It is second a Zope 2-like application server. I think that these folks aren't really interested in the (Zope 2-like) application server. Zope 3 will continue as a project (or projects) for creating and refining these technologies. (It would probably make sense for this activity to to have some name other than "Zope". On some level, the logical name would be "Z" (pronounced "Zed" :). An argument against "Z" is that it would be hard to google for, but Google handles such queries quite well and I'd expect that we'd move to the top of Google Z search results fairly quickly. However, I'll leave naming decisions to experts. ;) Advantages of this vision: - Zope 2 users don't need to leave Zope 2. - Zope 3 doesn't have to reproduce all Zope 2 features. - There wouldn't be confusion about 2 Zopes. It is important that Zope 5 be backward compatible with both Zope 2 and Zope 3, although not necessarily in the same configuration. Many people are building Zope 3 applications today and they should not be penalized. Thoughts? 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

24 70

Zope 3 / Z3ECM April sprint in Paris at Nuxeo
by Stefane Fermigier 06 Mar '06

06 Mar '06

Nuxeo, with the kind help of the Zope team of Chalmers University, plans to organise a Zope 3 sprint on April 3-7 in our premises in Paris. The focus of the sprint, like last year's successful sprint, will be ECM (Enterprise Content Management). Last year's Paris sprint was a turning point for the Zope roadmap, when it was decided to include Five in Zope 2.8, a decision which led to the current state of the Zope landscape (CMF 2.0 / CPS 3.4 / Plone 2.5 / Silva 1.5 - all full of Zope 3 components, etc.) We hope to make similar significant advances this year. Program: The current state of Z3ECM is currently best described in these slides: http://www.z3lab.org/sections/news/z3ecm-roadmap-september8593/ as well as on the www.z3lab.org website itself. 4 main themes for the sprint are currently emerging: - Repository: there is some unfinished conceptual and preliminary implementation work to be done regarding document repository design (including relations between documents, ORM-based storage, etc.) Ref: http://www.nuxeo.com/publications/slides/versioning-and-relation/downloadFi… http://www.z3lab.org/sections/front-page/design-features/ecm-platform-conce… - CPSSkins v3: Jean-Marc Orliaguet already has a very advanced implementation, that currently is Zope 3 only. We plan to bridge it with Zope 2 using Five to make it available on the current CMF-based platforms (at least CPS 3.4). Ref: http://www.z3lab.org/sections/blogs/jean-marc-orliaguet/archive_view?catego… http://svn.z3lab.org/trac/z3lab/browser/cpsskins/branches/jmo-perspectives/ - AJAX: we plan to generalize the current approach of CPSSkins v3, which is to use a JavaScript MVC library that exchanges JSON data structures with the server, to all the AJAX interactions. Ref: http://blogs.nuxeo.com/sections/blogs/tarek_ziade/archive_view?category=AJAX http://www.z3lab.org/sections/blogs/jean-marc-orliaguet/archive_view?catego… - XForms: we intend to make XML Schemas and XForms the new model for documents and their representation in Z3ECM. This is specially important for interoperability with the Apogee project (http://apogee.nuxeo.org/) Ref: http://blogs.nuxeo.com/sections/blogs/eric_barroca/2005_09_05_ajax-does-not… At Nuxeo, we intend to make all these developments available either on top on CPS 3.4, or for the next iteration of CPS (CPS 3.6). But we'd also like to share these developments with the rest of the Zope 3 / CMF / Plone / etc. communities, if they are interested. Participation: The sprint is open to experimented Zope 3 / CMF / CPS / Plone developers. We already have booked 4-5 developers from Nuxeo, and Jean-Marc Orliaguet and Dario Lopez-Kärsten from Chalmers. Please join the discussion on the z3lab mailing list (http://lists.nuxeo.com/mailman/listinfo/z3lab) or contact me (sf(a)nuxeo.com) if you would like to participate. The sprint is free (but you have to pay for your own travel and accomodation). We (Nuxeo) will modestly provide free pizzas / sandwiches / diet Coke, etc. NB: the dates (3-7 April) have been chosen so that long distance travelers can go to the Swiss sprint afterwards (8-13 April). If this is inconvenient for a majority of sprinters, we may change to the week after the Swiss sprint (17-21 April) but this change has to be decided quickly. I will confirm the date in a later announcement (next week). So, once again, let's followup on the z3lab list. S. -- Stéfane Fermigier, Tel: +33 (0)6 63 04 12 77 (mobile). Nuxeo Collaborative Portal Server: http://www.nuxeo.com/cps Gestion de contenu web / portail collaboratif / groupware / open source!

1 1

FrOSCon: Call for Projects / Last Call for Papers
by Lars Ehrhardt 05 Mar '06

05 Mar '06

Hi, we would like to invite you to FrOSCon, a two-day conference on free software and open source, which takes place on 24th and 25th June 2006 at the University of Applied Sciences Bonn-Rhein-Sieg, in St. Augustin near Cologne, Germany. Focus of the conference is a comprehensive range of talks about current topics in free software and open source. Furthermore, space will be provided for developers of free software and open source projects to organize their own developer meetings or even their own program. FrOSCon is organized for the first time in 2006 by the department of computer science in collaboration with the Linux/Unix User Group Sankt Augustin, the student body and the FrOSCon e.V., and aims to establish itself as the largest event of its kind in Rhineland. === Projects === Successful projects form the backbone of the open source and free software movements. FrOSCon wants to acknowledge this important role of projects for the community by offering special facilities to individual projects. === Developer Rooms === Open source and free software projects are often coordinated primarily via the internet, via email, the web and IRC. Nonetheless, personal contact between members of the project is of paramount importance. A conference like FrOSCon can serve as a meeting place, where distant members of the project can come together and meet. FrOSCon wants to offer dedicated developer rooms to individual projects, which are organized by the projects themselves. Thereby, we provide a space for projects to hold special-interest talks or meetings, to congregate, exchange views and to socialize. We have rooms in different sizes suitable for small developer meetings up to sub-conferences. We offer Internet access in all developer rooms. Besides tables and chairs, most rooms are or can be equipped with a video beamer. If necessary, an additional lecture hall can be assigned for talks or presentations where a larger audience is expected. === Application === Please send applications for a developer room via email to projects(a)froscon.org. Please include at least the name of your project, the URL of your website and the expected number of participants in your email. The Call for Projects ends on March 31st. === Call for Papers === Please note that our Call for Papers is still open until March 15th. Don't miss the chance to submit a talk. You can find all the details about the Call for Papers here: http://www.froscon.org/wiki/CallforPapers === Booth Space === If your project wants to man a booth at FrOSCon, feel free to contact projects(a)froscon.org as well. We are looking forward to hearing from you. Kind regards The FrOSCon team -- FrOSCon - Free and Open Source Software Conference Bonn/Rhein-Sieg http://www.froscon.org

1 0

Two visions?
by Geoff Davis 05 Mar '06

05 Mar '06

+1 on Jim's suggestion #2. However, if I am understanding things correctly, it doesn't really sound like door #2 entails a huge deviation from from our current course of bringing Zope 2 and Zope 3 together gradually. I don't really care what the converged product is called, be it Zope 2.250 or Zope 3.99 or Zope 5. My take is that Jim is not really proposing anything all that different from what Martijn wants -- a gradual convergence of Zope 2 and 3. Rather, it sounds like the biggest changes in Jim's proposal #2 entail: 1) a change in how we _talk_ about what we are doing, and 2) an explicit attempt to factor out some of the Zope 3 goodness into a more generic, less-monolithic-app-server framework, Zed (or Z or ZomethingElse). Am I right here, Jim? I think that the idea of giving Zed its own, distinct identity is great. Zope 3 is a _huge_ overhaul and it needs to be obvious to the world that it is dramatically better than crufty old Zope 2. Zope 3 then becomes the Zed application server; Zope 2 is getting Zed retrofits via Five, and the two will eventually converge into Zope 5 (or Zope 2.27 or whatever). A distinct Zed distribution could bring in developers who are just interested in using the component architecture but not necessarily a big app server stack. It would be cool to see Zed popping up in random python products or perhaps even in TurboGears / Django internals. And more than just cool -- the more people we can get using Zed, the more code we will be able to mix in easily to Zope (2/3/5) applications. Geoff

11 18

Re: [Zope3-dev] Re: Two visions?
by Max M 04 Mar '06

04 Mar '06

Rocky Burt wrote: > On Fri, 2006-03-03 at 09:30 +0100, Max M wrote: > >>Benji York wrote: >> >>>If we want people outside of the zope community to use these components, >>>they should not have the word "zope" anywhere in their name. If it says >>>"zope" people will *always* assume it is for use only with/inside Zope >>>(Zope 2 more often than not). >> >> >>Would we want people outside the community to do this? > > > We want as much as the python developer as possible to use pieces of > zope. This means those pieces of zope will have had greater testing, > more reviewing, and ultimately, more people contributing. I am *not* against other developers using bits of Zope. So I am sort of being the devils advocate here. But everytime it is mentioned, it is allways mentioned as a purely good thing. But it is in fact not without cost. Eg. conflicting interrests of 'external' and 'internal' users, or code that becomes more complex because of different use cases. -- hilsen/regards Max M, Denmark http://www.mxm.dk/ IT's Mad Science

1 0