Re: [Zope3-dev] Re: [Zope-dev] Two visions
Martijn Faassen wrote: Jim Fulton wrote: [snip] I think that having one name for two radically different, though related, things is very confusing. There are really 2 main technologies that people care about: 1. The Zope app server. This is characterized by things like an object file system, through-the-web scripting and/or development, pluggable course-grained add-ons, etc. I must warn you that what you call 'app server' is not what I call app server; I believe that using the word appserver for this set of technologies could be very confusing to people. I believe Zope 3 is an application server. I believe, say, Django is an application server too, even though as far as I know it lacks an object file system and through the web scripting. Can we find another word for what you mean? I wasn't trying to define app server. I was describing the Zope app server. 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 - Zope-Dev@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 )
Re: [Zope3-dev] Re: [Zope-dev] Two visions
Jim Fulton wrote: Martijn Faassen wrote: Jim Fulton wrote: [snip] I think that having one name for two radically different, though related, things is very confusing. There are really 2 main technologies that people care about: 1. The Zope app server. This is characterized by things like an object file system, through-the-web scripting and/or development, pluggable course-grained add-ons, etc. I must warn you that what you call 'app server' is not what I call app server; I believe that using the word appserver for this set of technologies could be very confusing to people. I believe Zope 3 is an application server. I believe, say, Django is an application server too, even though as far as I know it lacks an object file system and through the web scripting. Can we find another word for what you mean? I wasn't trying to define app server. I was describing the Zope app server. Jim why not say that the Zope application server is based on the Z Foundation Libraries (ZFL) ? Z can be interpreted as being short name for Zope without creating a new name for it. which can also be interpreted as the libraries used by the zope foundation software (ZF)? /JM ___ Zope-Dev maillist - Zope-Dev@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 )
Re: [Zope3-dev] Re: [Zope-dev] Two visions
Martijn Faassen wrote: Jim Fulton wrote: Martijn Faassen wrote: [snip] Sounds like the original vision of Zope 3 without the X. I thought we never got around to developing this stuff the last time. Actually, no. We originally said that we would provide a transition path. I said over and over that this was *not* going to be backward compatibility. I guess this was too complex a message. I think your post proves that it was. I know exactly what was said, and we, the Zope community, said it wrong, including the backwards compatibility bit. I quote the release notes for Zope X3.0: The X in the name stands for experimental, since this release does not try to provide any backward-compatibility to Zope 2. What do you think that implied? Maybe you didn't say backwards compatibility, but our release notes certainly said something about this. This message wasn't new: 1b. Zope 3X is the preliminary version of Zope 3. It is built from the ground up, paying attention to the lessons learned from Zope 2 and CMF. It is not a product but intended to let developers get familiar with the new architecture early. 1c. Zope 3 is the mainline release intended for production use and including backwards compatibility to Zope 2. It was here: http://cvs.zope.org/Zope3/doc/security/background.rst?rev=1.3 It is frustrating that there were worded this way. If was never intended that we would promise backward compatibility. I certainly tried to be clear that there would be a transition path, not backward compatibility. But perhaps we are splitting hairs... I had a lot more to say in this posting which I recommend you read: http://mail.zope.org/pipermail/zope3-dev/2006-February/017939.html You seem to be calling vaporware on even a transition path, implying that we shouldn't promise one. (BTW, vaporware is software that is described as if it exists, but doesn't. I don't think that applies to anything we are talking about here.) I think that a transition plan for Zope 2 applications is critical and something we should work toward. I don't see how *saying* what Zope 5 will contain will make it *exist* any time sooner. You seem to be arguing against a roadmap, which is puzzling. Obviously, predictions of the future are imperfect. I'm not arguing against a vision. You fooled me. I'm worried about marketing and what we will be implicitly implying. I want to be very careful about roadmaps as we can't guarantee they will happen, Of course we can't. and broken promises in this will be worse than no promises at all. I understand this. I'm more worried about roadmaps that aren't honest. That say we're working on something that we are not. I think, for now, our vision should be sketched with what we have right now (Zope 2 and Zope 3) and where we think they are going. Exactly. Talk about it names we already know, or if we really make new things, new names that are not Zope for the time being. We'll have to agree to disagree. [snip] The current story of Zope 2, Five and Zope 3 gets us in the right direction (Zope 5, if you want to call it that, though I would definitely want to introduce yet another name in the mix), step by step. We don't promise too much to people. We don't raise the wrong expecations anymore. What expectations did we raise? See my referenced mail: http://mail.zope.org/pipermail/zope3-dev/2006-February/017939.html I think it was right to raise expectations for a transition plan. Also, as I understand Zope 3 better, I feel that bacward compatibility *is* possible, at least to the extent that Zope 2 releases are backward compatible today. AFAIK, the official story is that Zope 3 will eventually replace Zope 2 and that Zope 2 will be augmented with Zope 3 technology to make the transition easier. I don't think there are many people, if any, really working on making Zope 3 a credible replacement for Zope 2. There are people working on making it into something wonderful, but not a replacement for Zope 2. Do you agree that this is the current story? If not, and if *we* cannot agree on what the current story is, think how confused everyone else must be. I think that is indeed the current story. Cool, we agree on something ... It's not complete: I think it is also inaccurate, because I don't think people working on Zope 3 are really working to replace the functionality in Zope 2. In fact, most of the work on Zope 3 is not on Zope 3 itself, but on integrating it into Zope 2. Zope 3 technology is replacing Zope 2 today in that I can write a Zope 3-like application in Zope 2. In that sense, Zope 2.9 *is* the Zope 3 without X. Zope 3 technology is not only in Zope 2 for the transition, but also because it's cool stuff we can actually use profitably now, not only because we might be able to transition to Zope 3 more easily in some future. This is much closer to the new vision that I proposed than the current vision. I
[Zope-dev] Principles
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 ___ Zope-Dev maillist - Zope-Dev@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 )
[Zope-dev] FrOSCon: Call for Projects / Last Call for Papers
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 ___ Zope-Dev maillist - Zope-Dev@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 )
