Re: [Zope3-dev] Re: Some thoughts on Zope 3, Zope 3 applications, and Zope 3 instances
On Fri, 2007-01-05 at 10:22 -0500, Jim Fulton wrote: Martijn Faassen wrote: Just splitting stuff up into little flexible pieces won't attract people. If our goal is to attract Zope 3 developers we need to make it easy to get started. We can also say that Zope 3 is componentized and flexible and all that, and this will attract developers too, but if the first bit is too hard all our talk about flexibility will lead to nothing. So, we need to do both: make it easy to get started, and componentizing for greater flexibility later. If we just do the first, we make Zope 2 style mistakes and end up with a monolithic system that should be easier to develop with. If we just do the latter, we make Zope 3 style mistakes and end up with a well componentized system that isn't used a lot. Agreed, we need both. We should understand though that the thing I'm calling (soley for the sake of discussion) is probably not a good starting point. IMO, it could be if someone was working on it. I also think that it would be a find project on it's own. Or maybe there's another project that would serve better. I don't know. I'm coming in to this discussion very late but if one goal is to enable the creation of OFS-like applications on top of an OFS-less application server, does anyone have recipes for building the latter that could be used as a starting point? - Michael R. Bernstein michaelbernstein.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Some thoughts on Zope 3, Zope 3 applications, and Zope 3 instances
snip / As a non-developer observer, I'm +1 with Jim's discussion. Martin, you're right that developer influx should be the key goal, and that (a) simpler entry points like Grok and (b) killer apps are the way to get to that goal. and I think things like grok are the natural progression from drink our koolaid to use our koolaid mix and make your own. I don't think the killer app, though, should be the responsibility of the Zope project. More bluntly, I don't think it's fair to tell the Zope 3 core team to do it: they are more interested in machinery, they don't need to do it for their jobs, and are already giving us plenty. Let's decrease the responsibilities of the core. (Note: 3 years ago I lobbied heavily for the Zope 3 to keep the TTW dream alive, but my thinking was flawed.) everything has it place, scope creep on perfectly good ideas causes the pain. for example: the acceptance of the ZODB *would* benefit greatly from some type of database browser; such an application would not need to be a full blown application server. -w ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Some thoughts on Zope 3, Zope 3 applications, and Zope 3 instances
On Jan 6, 2007, at 7:19 AM, Martijn Faassen wrote: Jim Fulton wrote: Martijn Faassen wrote: [snip] Just splitting stuff up into little flexible pieces won't attract people. If our goal is to attract Zope 3 developers we need to make it easy to get started. We can also say that Zope 3 is componentized and flexible and all that, and this will attract developers too, but if the first bit is too hard all our talk about flexibility will lead to nothing. So, we need to do both: make it easy to get started, and componentizing for greater flexibility later. If we just do the first, we make Zope 2 style mistakes and end up with a monolithic system that should be easier to develop with. If we just do the latter, we make Zope 3 style mistakes and end up with a well componentized system that isn't used a lot. Agreed, we need both. We should understand though that the thing I'm calling (soley for the sake of discussion) is probably not a good starting point. I think I miss a word here; the thing you're calling what? Sorry, OFS IMO, it could be if someone was working on it. I also think that it would be a fine project on it's own. Or maybe there's another project that would serve better. I don't know. I'm trying to understand what you're referring to here. :) I'm referring to the application we've been distributing in Zope 3 releases, which, for the sake of discussion, I've been calling the OFS and you've been calling the ZMI. Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Some thoughts on Zope 3, Zope 3 applications, and Zope 3 instances
Martin Aspeli wrote: The general direction that web frameworks are moving in, led by Rails and to a certain extent Django, Pylons, TurboGears and arguably Plone in some circumstances, is that getting started must be quick, results must be rapid, the tools must support agile working practices and the learning curve must be managable. It was a long time ago and easy to forget, but this was what Zope(2) provided at a time where there was nothing else even close. Suresh ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Some thoughts on Zope 3, Zope 3 applications, and Zope 3 instances
Jim Fulton wrote: Martijn Faassen wrote: [snip] Just splitting stuff up into little flexible pieces won't attract people. If our goal is to attract Zope 3 developers we need to make it easy to get started. We can also say that Zope 3 is componentized and flexible and all that, and this will attract developers too, but if the first bit is too hard all our talk about flexibility will lead to nothing. So, we need to do both: make it easy to get started, and componentizing for greater flexibility later. If we just do the first, we make Zope 2 style mistakes and end up with a monolithic system that should be easier to develop with. If we just do the latter, we make Zope 3 style mistakes and end up with a well componentized system that isn't used a lot. Agreed, we need both. We should understand though that the thing I'm calling (soley for the sake of discussion) is probably not a good starting point. I think I miss a word here; the thing you're calling what? IMO, it could be if someone was working on it. I also think that it would be a find project on it's own. Or maybe there's another project that would serve better. I don't know. I'm trying to understand what you're referring to here. :) Anyway, I think Grok is one concrete project that's making it a lot easier to get started with Zope 3 technology. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Some thoughts on Zope 3, Zope 3 applications, and Zope 3 instances
Martin Aspeli wrote: Jim Fulton wrote: I'll make some small comments below, but I want to make a big comment to start. Zope 2 and Plone are both examples of extensible applications. In my note, I was trying to make the point that I think such applications have value. I'd like to see them exist. I'd like to see them done well. I think Zope 2 did it very well, in it's time. I think Plone and other applications have carried that forward successfully. At ZC, for better or worse, we are no longer in the business of applications that are extensible in that way. We build applications that are used directly by our customers. I think this is true of many Zope developers. *We* use Zope 3 as a library for building applications. Both uses are valuable and should be supported. The application that I've been referring to as the OFS (again, a more or less random name) is a pale imitation of Zope 2. This is very much what I read into your comments and I think it is an impotant architectural decision whether we're building an application or a framework (Plone itself struggles with that decision sometimes); The strong framework leaning that Zope 3 has adopted is probably to its benefit, and is almost certainly the main reason why we are able to benefit from Zope 3 at all today in the Plone universe (via Five). However, Zope 3 should not be and is not just a library that ZC and a few other people with deep investment in the framework use for their applications. To grow, stabilise, mature and become a good vehicle for selling work (I trust you because you're using Zope 3, rather than, I don't trust you becuase you're not using J2EE) the community needs a constant influx of new developers and interested parties - the first instance, users of the framework. The general direction that web frameworks are moving in, led by Rails and to a certain extent Django, Pylons, TurboGears and arguably Plone in some circumstances, is that getting started must be quick, results must be rapid, the tools must support agile working practices and the learning curve must be managable. Most people don't have the time to bet that reading a book or two will be worth the investment (of time) before they start doing something useful and productive. This to me is where we can learn from the success that Zope 2 and Plone have enjoyed (or been the victim of, as it may be architecturally speaking). The main reason people think about building applications in Plone at all (a somewhat self-contradictory notion) is that if they can re-use all the pretty UI and HTML/CSS primitives and user management and navigation elements and security and workflow from Plone, turning off the portlets and content types and junk they don't need and turning on the custom look-and-feel and extra content types and portlets and forms they *do* need, they get something up and running quicker, to a higher standard, than if they start from a palette of components and a blank .py file. In other words, as Martijn has said, I believe it is very important for the community to support meaningful distributions/app servers/higher level frameworks (singular or pural) that show off what Zope (3) is good at and how it's done, that can be customised and (this is where the CA approach really kicks ass) where future upgrades to this means you benefit, not that you need to re-fork it for your own needs. I would be worried if I felt that the Zope 3 community became only about components and left this real world but generic assembly work to someone else when no someone else would be interested or skilled or emotionally invested enough to care. In the Plone world, we have the focus of Plone-the-application that implies we have to make Plone-the-framework better. If things become *too* scattered, where is the focus of Zope3? (note: I'm exaggerating here, I think things are moving in the right direction not the wrong one, I'm just playing devil's advocate and exploring what I've seen from the Plone side of the fence) Note that there is nothing inherently hierarchical about ZODB. Of course, ZODB makes modeling hierarchies (and other graphs) much easier in many ways that working with non-object databases. Of course, I'm a big fan of the ZODB and would use it for all sorts of non-content-centric apps, whatever that means. :) Like I said, I'm quite tainted by Zope2/CMF/Plone. I like to model (many/some) problems as hierarchical data structures with concepts like one-to-many relationships as folders with content. I agree the ZODB isn't necessarily hierarchical, but all the use cases I've ever seen for it have been. :) Well, fortunately, thanks to setuptools and tools like easy_install and zc.buildout, you should only need one trip to the cheese shop (or wherever) and the dependencies should come along automatically. I'm also working on ways to automate packaging and app and all of it's dependencies together. That would be another useful step. I still find it a bit
[Zope3-dev] Re: Some thoughts on Zope 3, Zope 3 applications, and Zope 3 instances
Martijn Faassen wrote: My hope is that with Grok we can inject some sensibilities into Zope 3 that focus more on getting things done easily and quickly. I think that the basis built with an attitude of reusable and flexible components is great to build a powerful getting things done easily and quickly system on top. But we really really need such a system, and I hope Grok will be more than just a new technology but will also help drive a shift in focus in the Zope 3 world. And I fully support it; it's even conceivable I could contribute one day, if I find time. This project is really exciting and deserves more traction than it has at the moment. It would be very interesting also if there was a path through which Plone developers and other Five-dependents could start using Grok productivity boosting tools. We have core Zope 3 developers here at this sprint (Philipp, Christian Theune), so I have some hopes we'll succeed. :) ... but it is a fine team :) So, I agree we need what Jim proposes. We just also need what Grok tries to offer. I think that as an open source development community that wants to grow, we need Grok a lot more than we need splitting up Zope 3 into eggs. +1, though perhaps one makes the other easier. Martin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Some thoughts on Zope 3, Zope 3 applications, and Zope 3 instances
Paul Everitt wrote: Thus, telling the Zope 3 core team to own and distribute the killer app is neither realistic nor fair. Move Zope 3 to its natural turf and collaborate with folks that feel passionate about other turf. Application != the framework. A very good point. Perhaps the future will be: Developer learns Grok. Developer likes Grok. Developer improves Grok. Developer finds that to improve Grok, he should help improve Zope 3. And then maybe s/Grok/Plone/g or s/Grok/something else/g. I'm obviously not in the business or position of telling people what to do (well, ahem, maybe I do, at least in the Plone world, but that's mostly just good intentions). My concern is that we should make the framework accessible and approachable, and that having a focal point and a path through the framework is an important part of that. Grok is encouraging to me in that regard. Plone is quite actively (but not wholesale any time soon) moving in a direction where it becomes a strong consumer of Zope 3. Hopefully, we'll see something else emerge as well that is conceptually a combination of the two: End user-oriented and pure Zope 3. I don't think anyone's argued otherwise, of course, I'm just pointing to existing wisdom I've received and observed. Martin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Some thoughts on Zope 3, Zope 3 applications, and Zope 3 instances
On 1/6/07, Martin Aspeli [EMAIL PROTECTED] wrote: Hopefully, we'll see something else emerge as well that is conceptually a combination of the two: End user-oriented and pure Zope 3. The only issue here is whether Zope 3 itself is useful directly to end users, or something built on top (regardless of whether that's the OFS or something else). The issue that seems to be slightly controversial is whether the Zope 3 core developers should be responsible for that application. I don't think anyone's argued otherwise, of course, I'm just pointing to existing wisdom I've received and observed. I think we're all in agreement on this. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Every sin is the result of a collaboration. --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Some thoughts on Zope 3, Zope 3 applications, and Zope 3 instances
Hi Jim Martijn, For xParrot we have a case in point where the ZMI both helped and confused us. Because of the way the documentation is 'framed' (where available) it lead us to believe, initially, that ZOPE was the ZMI. The first incarnation of xParrot (an XML/XSLT provider) was intermingled with the ZMI. The next version two was mostly about driving the ZMI out of the equation. The OFS (if I understand correctly we are referring to the file/object representation of ZOPE) is still very valuable for reaching resources. In fact xParrot2 does not use the ZMI at all now but would not be what it was without the OFS. On the other hand for another project I use the ZMI and the Rotterdam skin to develop faster - providing a useful tree interface. The tree is key here. It is obvious reflection/inspection etc. are quite useful too, during development. I would suggest to accentuate the library side of ZOPE and provide the ZMI as a (lesser) example. For ZOPE3 to replace ZOPE2 a new application engine may be an idea. A powerful engine that is better than Rails - with some code generation - should be an enticing goal for some. Because, take it or leave it, programming with ZOPE is still (too) hard. I learnt Ruby on Rails in a few days. With ZOPE3 I often still am in the dire straights (after a year). We use ZOPE3 because of the superior component model and because it looked better for xParrot, at the time. And in fact, we have no regrets there as Andrew designed xParrot so it can be used without any understanding of Python/ZOPE now. So, there you have one great application without the ZMI. Let me wrap up saying that despite my criticisms I think you all did a great job. The stability and robustness of ZOPE3 is legendary. Deployment is a bit odd, but one gets used to that (I agree about the duplication - but then that is configuration too, it is not that bad). A strong 2007 wished for. Pj. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Some thoughts on Zope 3, Zope 3 applications, and Zope 3 instances
Martijn Faassen wrote: Martin Aspeli wrote: [snip] I think your thoughts resonate quite well with my own observations and/or confusion. I would, however, caution against becoming over-zealous in breaking things up. Zope 2, CMF and Plone are successful in large part because people get started quickly. If it takes fifteen trips to the cheese shop to understand how to get a page to say Hello world, I'm not sure people would bother. Most likely, that's solved by having use-case focused (and real-world tested) bundles or distributions that provide meaningful functionality of starting points. It's also solved by having some customisable best-practice components that are closer to the user. Learning from such examples is probably the main way people pick up new technologies and conceptualise how they can solve their particular use cases. +1 here. Just splitting stuff up into little flexible pieces won't attract people. If our goal is to attract Zope 3 developers we need to make it easy to get started. We can also say that Zope 3 is componentized and flexible and all that, and this will attract developers too, but if the first bit is too hard all our talk about flexibility will lead to nothing. So, we need to do both: make it easy to get started, and componentizing for greater flexibility later. If we just do the first, we make Zope 2 style mistakes and end up with a monolithic system that should be easier to develop with. If we just do the latter, we make Zope 3 style mistakes and end up with a well componentized system that isn't used a lot. Agreed, we need both. We should understand though that the thing I'm calling (soley for the sake of discussion) is probably not a good starting point. IMO, it could be if someone was working on it. I also think that it would be a find project on it's own. Or maybe there's another project that would serve better. I don't know. 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 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Some thoughts on Zope 3, Zope 3 applications, and Zope 3 instances
Jim Fulton wrote: Martin Aspeli wrote: ... Anyway - I hope these perspectives are useful. I'm certainly not disagreeing with what you're saying or with the direction you're pointing out. I think we just need be mindful that there were some good things about the past approaches as well as problems (not that you're not). I think we're in strong agreement. I think we need both the Framework and the apps that use the Framework, including Zope2/Plone-style pluggable apps. I think we need to keep these efforts somewhat distinct though. I'd love to see projects that focus on building killer apps on top of the Zope 3 framework. I just want people to understand that the application != the framework. My argument is just that if you're not careful, you may end up with a chicken (or was that xicken) and egg situation; not enough people who know the framework care to build the killer app(s); not enough people who need an app understand (or have time to understand or will risk spending the time on something they don't fully understand) the framework. Someone with the right skills needs to passionately care. Perhaps it's OFS+ZMI; perhaps it's Zope 2 + Five; perhaps it's Plone (man, you have no idea how productive you excellent people have made some of us jaded Plone developers recently); perhaps it's Grok; hopefully some combination. Martin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Some thoughts on Zope 3, Zope 3 applications, and Zope 3 instances
Jim Fulton wrote: [snip] The current Zope 3 distribution also contains an application that resembles Zope 2 in many ways. There is an object tree and a Zope Management Interface. At least up to now, when you install a Zope 3 distribution, you get an application that you can run out of the box, for whatever that's worth. In this document, I'll call this application the the Object Filing System (OFS). I've found the OFS to be useful when developing Zope 3 itself. The OFS was really the first application developed with Zope 3. There are also certain kinds of applications that can use the OFS as a starting point. We've built content-management systems that reuse much of it. In the later case, we've used it less as an application than as a library. It's not obvious to me that that the OFS has much value as an application in it's current form. In development I've typically used bits and pieces from the OFS as a library. That is, I used the OFS components but didn't care much about the ZMI user interface on top of it. I'm not sure whether your OFS is my ZMI, but I'll talk about the ZMI here in the hope it's close enough to what you mean. If not I hope my discussion is valuable in its own right. :) I do think there is room for a management interface that allows you to inspect object state and do some simple configuration, but it should be focused narrowly and not aim to be an TTW application development environment or content management system or a reusable user interface framework. We are hoping to develop a management interface like that for Grok at some point (I'm currently in Germany for grok sprint 2). [snip] My current thinking, FWIW: It's not clear to me that the Zope 3 application we now distribute has much value. I'd be interested to hear other people's thoughts on this. I'd like to see some popular Zope 3 applicaton or applications that people download and use to get excited about Zope 3. I don't know if anyone is developing something like that. I hope they are. I don't think anybody is trying to turn the existing OFS into an application like that. I'd like to rephrase this and say I don't think (or hope) that someone is trying to turn the existing Zope 3 ZMI into an application like that. I like having simple base classes like Folder and File around that I can reuse or inherit from. We're hoping to supply these with Grok though. Something OFS-like and simple would have its place in my view of the terminology. :) While I fully support Zope 3 becoming a library and toolbox of reusable bits, I also want to emphasize that it's very important for Zope 3 to have obvious ways to do things, preferably one obvious way to do it. Of course the underlying system should be flexible, but the code that people will be reading should be clear and easy to understand. This is where popular Zope 3-based applications come in: they serve as sample code for the applications following them (no matter whether they want to be sample code or not). [snip] In summary, I'm seeing Zope 3 applications as separate entities from the OFS. The OFS application isn't something we'll use directlty. Instances will be instances of our applications, not of Zope 3. I think this pattern is a good approach. I do think that it is valuable to emphasize that each instance has some common features: you could for instance support a debugging or management UI that can be optionally enabled for each of them. This allows for commonality and also the feeling that people get more out of the box than a lot of tools they may not know how to apply effectively. None of this should be taken as any sort of edict. I'm also not trying to name anything. While I'd love to spur discussion, I hope not to start any arguments. :) The current ZMI is currently doing some things for us (however badly), so we should analyze what it does: * first user experience. I install zope 3 and can vaguely click around the ZMI. Not much, but at least I have the feeling what I installed works and is doing obscure things. * it is a user interface that helps with installing applications. Multiple instances of an application may be deployed under the same port number. I think this is a valuable feature, and allows the possibility for multiple cooperating applications without having to open new ports for each of them. You can use the ZMI to install multiple Document Library instances, for instance. * it's an introspection and debugging interface. My application is broken during development and deployment and I can go into the ZMI and see what's wrong. I can look at various local configuration settings. * it can be a configuration interface. Not only complicated stuff like installing local utilities, which I hope can move mostly to declarative code instead, but also simple stuff like which exceptions are logged can be configured. What else? We should figure out what we want to (and
[Zope3-dev] Re: Some thoughts on Zope 3, Zope 3 applications, and Zope 3 instances
Martin Aspeli wrote: [snip] I think your thoughts resonate quite well with my own observations and/or confusion. I would, however, caution against becoming over-zealous in breaking things up. Zope 2, CMF and Plone are successful in large part because people get started quickly. If it takes fifteen trips to the cheese shop to understand how to get a page to say Hello world, I'm not sure people would bother. Most likely, that's solved by having use-case focused (and real-world tested) bundles or distributions that provide meaningful functionality of starting points. It's also solved by having some customisable best-practice components that are closer to the user. Learning from such examples is probably the main way people pick up new technologies and conceptualise how they can solve their particular use cases. +1 here. Just splitting stuff up into little flexible pieces won't attract people. If our goal is to attract Zope 3 developers we need to make it easy to get started. We can also say that Zope 3 is componentized and flexible and all that, and this will attract developers too, but if the first bit is too hard all our talk about flexibility will lead to nothing. So, we need to do both: make it easy to get started, and componentizing for greater flexibility later. If we just do the first, we make Zope 2 style mistakes and end up with a monolithic system that should be easier to develop with. If we just do the latter, we make Zope 3 style mistakes and end up with a well componentized system that isn't used a lot. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
