Yeap, you’re pointing out exactly how high the tightrope is that we’re balancing on. :) The fact is, there are people out there right now- you might be one of them!- developing ZF components (components that play nicely with and likely depend on ZF ‘core’ components) that they would like to share with others either in their own company/projects and/or publically- and we haven’t addressed such components in any significant way as a framework. In fact, our proposal process right now is structured entirely around components on the ‘core’ track, and many perfectly useful components will never be serious core candidates because they aren’t useful to most developers for any number of reasons. I know that people really appreciate the simple packaging that we currently have with ZF, and we’re not about to take away one of the biggest value propositions to our developers. On the other hand, we’re growing rapidly as a community and a software package, and what made sense yesterday isn’t necessarily practicable today. I doubt any of us want a full packaging system, so it will be a matter of finding the right compromise AFAIC tell. We haven’t had much time to talk about it lately since many of us are so focused on 1.5, but soon after the release we will pick the discussion up again on this list.
BTW, I greatly respect and sometimes even consult with my predecessors, but the course of ZF is set by the opinions of the ZF community *right now*. It may be hard to keep up sometimes, but that is pretty much the story of the software industry and OS community at large. And ZF has to keep up in its own right. ;) ,Wil From: Kevin McArthur [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 05, 2008 11:28 AM To: Wil Sinclair Cc: Bradley Holt; Elliot Anderson; Simone Carletti; [email protected] Subject: Re: [fw-general] ZF Packaging Wil, I'll play devils advocate here. First, before everything else one must consider deployment, packaging and installed base. One of the great failures with PDO, and possibly one of its successes, was with its separate driver architecture. Practically, splitting it makes sense, pragmatically however, it has lead to serious configuration headaches for a lot of users. Zend Framework is the same, and your predecessors have expressed the importance in making sure that when a hosting package is selected that says 'Zend Framework v 1.X' it means all of it -- not a mix of components that will have to be detected at runtime. Worse, we could end up with independently versioned components aside from the core. Applications dependent on framework will then have to made even more intelligent, and deployment complexity increases significantly. I would point you to review the archives here, as versioning and optional components have been discussed at length before. There is something very powerful about Zend's currently unified deployment architecture. Kevin Wil Sinclair wrote: I generally like mootools’ and other JS libraries simplistic dependency model (AFAIC tell, the core lib is the only dependency allowed, so a general-purpose packaging system with tracking across full dependency graphs is not necessary). If we were to start distributing parts of ZF in a piecemeal fashion, I think that we would also see great benefit from a few basic rules aimed at drastically simplifying dependency management. While there is no immediate and significant runtime advantage that I can see here, we are interested in- and have been discussing- distributing at least one ‘lean and mean’ archive. There are several reasons for this, including lower load on our servers and- taking off my perfectly logical developer hat and putting on a more realistic marketing hat ;)- the fact that many developers and reviewers consider distribution size to be an important dimension on which to judge a framework. I don’t necessarily think that distribution size is a good indication of anything for a server-side framework beyond what you *can’t* expect to be included, such as sizable locale files which are very useful to our many international users but that add a MB or two to the current distribution of ZF (Thomas has done an excellent job getting these as small as possible while maintaining everything that makes them so useful in the first place), but I do think that the ‘download only what you need’ distribution mechanism is both technically and philosophically compatible with ZF in its current state. We’ll probably be talking about this more once 1.5 is out the door. ,Wil From: Bradley Holt [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 05, 2008 7:04 AM To: Elliot Anderson Cc: Simone Carletti; [email protected] Subject: Re: [fw-general] ZF Packaging Elliot, The main reason that mootools does this, in my understanding, is so that it can give you one JavaScript file to be included in your web page with only the components you need. There are performance advantages to this since you are only requiring the user's browser to get the JavaScript components it will need, not all of mootols. With Zend Framework, there is no performance advantage to only installing a handful of components. My understanding is that the performance hit comes when you require or include the component, not from it simply sitting on your web server. In other words, the main advantage of the pick-what-you-want download system doesn't apply when it comes to Zend Framework. The only advantage I can see is storage space, but have there been any complaints about that with Zend Framework? Thanks, Bradley On Feb 5, 2008 6:26 AM, Elliot Anderson <[EMAIL PROTECTED]> wrote: I'm a fan of the pick-what-you-want download system that Moo Tools has. http://mootools.net/download On Jan 29, 2008 6:04 AM, Simone Carletti <[EMAIL PROTECTED]> wrote: On Jan 28, 2008 3:57 PM, Richard Thomas <[EMAIL PROTECTED]> wrote: zfdev.com is a community supported project that never really took off, It was never an "official" repository though. Sorry Richard, my misunderstanding. :) Thanks for pointing it out. Simone -- Bradley Holt [EMAIL PROTECTED]
