Community Input 2.0 - One thing at a Time. (Was: A response to the community)
Locked
12
12
Community Input 2.0 - One thing at a Time. (Was: A response to the community)
 
|
Since there doesn't seem to be any interest by Zend in the community
having much, if any, ownership over 2.0's architecture. Lets look some of the issues one-by-one, and I think it will highlight where the issue is with letting Zend prototype everything. 1. Post-Redirect-Get tight integration for forms. This has been brought up time and again, and its pretty clear its not on the roadmap for 2.0. To do a component like this justice it needs links to Session, FlashMessenger, Forms, Filters/Validators, Database, etc.. its an architectural issue which is difficult to implement in an elegant way in the current framework. 2. Config.ini taking over. I really hate the current config.ini usage for core components. What should be a single point of configuration (ie the bootstrap) is turning into a web of mess when debugging -- worse, it doesn't work at all with code completion options, and it makes the framework a helluv a lot harder to debug/learn. The current roadmap for 2.0 seems to send us further down this rabbit hole. 3. Will Auth/ACL become a core concept in the dispatcher? There are a lot of benefits to getting this out of the current dispatcher flag cycling. 4. Context's. Mobile, Json, Language, etc. Is this the right way to handle different contexts. Since a lot of these questions need to be answered by decisions on the accept header, on the user agent, etc these types of dispatches could probably be tightly integrated with the front controller rather than as an add-on after the fact. 5. ORM integration. Zend_Db. Massive changes are needed here. Is Doctrine the solution, or just more api inconsistency? How will it be integrated? 6. *Helper patterns. Have they proved useful or detrimental. Can their impact on performance be analyzed? 7. Action Stacking. Major architectural issue here. Current solution was discontinued because it sucked. Can this concept be done correctly so that we develop small actions that have specific responsibility. 8. Layout/Composition Zend_Layout is great, but it needs a _lot_ more if it's to provide a solid and consistent foundation capable of competing with CMS products in the market. I realize ZF isn't a CMS, but standard regions for NAV, Headers, Footers, Content, etc... along with standard ways to inject content into this system would be a big improvement over the current partial and placeholder infrastructure. (Ever tried tracking down where a placeholder got _all_ of its content from in a complex application that has both views and controllers adding to placeholders... its almost impossible) 9. Zend_Tool Is the project going to railsified with Zend_Tool? Is that a good thing? If its an add-on/optional part of development, aren't we just making this beast even harder to learn? Do you copy files, do you zf bootstrap.... etc. Ztool still needs a lot of work, but if its going to be an integral part of zf2.0 dev -- then it should be just that. Does that demand a certain amount of metadata injected into autogenerated source files such that those files can be upgraded/managed by the tooling system? This architecture needs to be worked out as part of the 'core' ... imo. Will we be emitting database DDL from this system? Are we agreed on a standard format for that? 10. Resources from external libraries. With namespaces, it should now be possible to easily import controllers/actions/views/and other resources from other libraries. This is a huge issue with the current system for me in that, primarily, I work with a common library, customized on many sites. I want to include views/actions and override them from the stock set as needed. Handling this import of resources elegantly should be a key 2.0 architectural consideration. 11. Privacy and data tainting. The framework currently has no ingrained idea of data tainting. I think this should change, and was simply waiting until the 2.0 architectural discussion was started to propose some major changes in how we handle data moving throughout the framework. This is a key element to doing privacy assertions in multi-user environments. 12. Geospatial Elements. Large amounts of the web are going mobile, and therefore spatial. While some of this can be tacked on after 2.0 core is complete, are there architectural considerations for a system-wide concept of location. (Ie integrating tightly with accept-language, locale, translations etc) 13. HTML5 + EXTJS + jqtouch and other UI-model altering development. Does the current view helper approach make sense in RIA environment. What are we leaving on the table for other frameworks? Jqtouch is absolutely amazing, but its very hard to work with in the current zf model. As is ext-js, etc... I'd like to see architectural consideration in light of the fact that the development world is no longer page-view-centric. This goes back to my earlier item about actionstacking, contexts, etc. 14. PDF and document generation. (Third party integration) There are huge advances over the Zend Framework available in other libraries (full disclosure, Willie Alberty and I [both major contributors to the original PDF lib] forked the ZF lib into a new PDF project) but those libraries require much more flexibility than the current testing/coding standards require. The community needs to decide how external libraries will be integrated with the ZF, and on what policy principles collaboration with the other projects will work. I'm not advocating for inclusion of this lib, but the same issues apply to dojo, to gdata, to amf... etc. Which brings me to 15. App marketplace, phar, componentization. This is a huge thing missing from the Zend Marketplace. A way to share [and sell] third party libraries for Zend Framework. Everyone has a cool set of extensions, but very few are within the scope of the framwork itself. I'd like to see a place where you could go get objects for a shopping cart, or a blog, or whatever other pre-packaged type of thing will work with your project. This doesn't have to be the exclusive domain of the CMS's. That said, this requires a new packaging model, resource loading, (potentially phar integration), etc etc... huge architectural decisions. .... I could go on... but thats enough to stir the pot towards, and underline why we need both comprehensive community ARCHITECTURAL considerations and CODE LEVEL integration as well. Matthew cannot possibly solve all these points on his own. Nor can he solve the other 50 that aren't mentioned. ZF needs the community steering the direction of these features. It needs COMMUNITY OWNERSHIP over the project's path forward. Matthew for all his hard work cannot replace an interested and committed community. So, bring on the argument on a point-by-point basis. Will it get lost on the mailing list again? Will we get resolution? Will Matthew continue to be forced to go it alone, then plop the whole bloody thing down on the community for feedback, well after the timeframe for these massive questions have passed. This isn't the next version of windows and Zend isn't Microsoft. We're not here to help add-and-extend on a Zend core. Least thats not what I'm interested in calling the Zend Framework. I hope that explains where I'm coming from. Kevin McArthur |
|
Hey,
since I don't have much to add/say in regard to some issues, let me reply to others I feel stronger about. :-) On Thu, May 27, 2010 at 7:52 PM, Kevin McArthur <[hidden email]> wrote: > (...) > 2. Config.ini taking over. > > I really hate the current config.ini usage for core components. What should > be a single point of configuration (ie the bootstrap) is turning into a web > of mess when debugging -- worse, it doesn't work at all with code completion > options, and it makes the framework a helluv a lot harder to debug/learn. > The current roadmap for 2.0 seems to send us further down this rabbit hole. I disagree on the single configuration issue. That may make it easier for people to adopt and learn the framework - on the other hand it makes it harder for those of us who actually only use certain components - or not MVC, or not Zend_Application. All this zero conf/automation stuff is also expensive in terms of runtime. I don't want to create and setup Zend_Application if all I want is to use Zend_Http_Client. Generally, I prefer a common way to configure components - e.g. all components are configured with Zend_Config_Foo, or with something else. I wouldn't offer five different ways. If I misunderstood your issue, let me know. > (...) > 4. Context's. Mobile, Json, Language, etc. > > Is this the right way to handle different contexts. Since a lot of these > questions need to be answered by decisions on the accept header, on the user > agent, etc these types of dispatches could probably be tightly integrated > with the front controller rather than as an add-on after the fact. I don't agree here either. I agree that they could be extended or improved, etc.. But I prefer them the way they are. > 5. ORM integration. Zend_Db. > > Massive changes are needed here. Is Doctrine the solution, or just more api > inconsistency? How will it be integrated? Not a huge fan of ORMs to start with and I think Zend_Db served most people well. I also see that Doctrine does a lot, lot more but so is the learning curve. I'd still prefer a more simple approach to wrap the specifics of the different adapters. Doctrine (IMHO) should be optional and not required for RDBMS usage. > (...) > 14. PDF and document generation. (Third party integration) > > There are huge advances over the Zend Framework available in other libraries > (full disclosure, Willie Alberty and I [both major contributors to the > original PDF lib] forked the ZF lib into a new PDF project) but those > libraries require much more flexibility than the current testing/coding > standards require. The community needs to decide how external libraries will > be integrated with the ZF, and on what policy principles collaboration with > the other projects will work. I'm not advocating for inclusion of this lib, > but the same issues apply to dojo, to gdata, to amf... etc. Which brings me > to Generally - I get the notion (and correct me if I'm wrong) that ZF should be turned into this 3rd-party-library-agnostic "thing" that integrates with whatever. I think that's not going to happen, at least not from a plugin and play perspective. I don't think that should be a goal on the roadmap either. If you want to see a pretty successful model, I suggest you check out Rediska which is a library for Redis. Rediska ships with a driver for Zend_Session and Zend_Cache (and possibly others) already and if someone decides to write a driver for Cake or Symfony - well, that's the responsibility of the Rediska project and not really an issue for Symfony or Cake. More info here: http://rediska.geometria-lab.net/ There's really nothing wrong with integrating 3rd party libraries - just like a couple people are working on a tighter integration with Doctrine. If people would like something "in" ZF, they should work on it. If however the idea is to make ZF compatible with everything out there, development will drift away from core issues - as you mentioned yourself already. As for Gdata, dojo, etc. - JavaScripting, that seems to be covered already since there is an integration for jQuery in ZendX. And in regard to Gdata. I think Zend either needs to go out with Google for beers more often or they need to hire someone to take care of this component. It seems to require a lot of time to keep up with the development - maybe more than your average API. When I looked at Zend_Gdata a couple months ago, I thought it would be better to drop it from core to ZendX. Let alone all the basic coding issues that seem to have been overlooked in order to get it in (no offense meant). The bottom line from all my yapping: I think it doesn't help the framework to carry on all those extra components that look great for a press release but are really ridden with issues to the max. Gdata would be my example - over a 100 "open" issues. > 15. App marketplace, phar, componentization. > > This is a huge thing missing from the Zend Marketplace. A way to share [and > sell] third party libraries for Zend Framework. Everyone has a cool set of > extensions, but very few are within the scope of the framwork itself. I'd > like to see a place where you could go get objects for a shopping cart, or a > blog, or whatever other pre-packaged type of thing will work with your > project. This doesn't have to be the exclusive domain of the CMS's. With no offense, but I think this is more or less your own business. ;-) And I think this shouldn't be on the framework roadmap either. If anyone - e.g. you - wants to step up they can do that. If Zend wants to do it, that's cool too, but I don't think this should be another burden for the developers - neither Matthew or Ralph, nor any of the component leads from the community. My wishlist for 2.0: * commitment to the most necessary components and making them awesome (!) * completely revamping Zend_XmlRpc, Zend_Rest (!) and Zend_Session * more DSLs (e.g. in Zend_Http_Client) * writing code with performance in mind * more open proposal process Till |
Re: Community Input 2.0 - One thing at a Time. (Was: A response to the community)
|
|
till wrote: I'm actually arguing _against_ the config.ini approach. I much prefer the old-style bootstrapping. One point of responsibility.
Ok, so what I was referring to here is that some components play by one set of rules (full Zend process) and others by the rules of a third party. What is the policy to decide on including third party components or a Zend Framework port. In general I agree that these components bloat the framework. That said, they exist and there should be policy for how/when this type of thing occurs.As for Gdata, dojo, etc. - JavaScripting, that seems to be covered already since there is an integration for jQuery in ZendX. And in regard to Gdata. I think Zend either needs to go out with Google for beers more often or they need to hire someone to take care of this component. It seems to require a lot of time to keep up with the development - maybe more than your average API. When I looked at Zend_Gdata a couple months ago, I thought it would be better to drop it from core to ZendX. Let alone all the basic coding issues that seem to have been overlooked in order to get it in (no offense meant). The bottom line from all my yapping: I think it doesn't help the framework to carry on all those extra components that look great for a press release but are really ridden with issues to the max. Gdata would be my example - over a 100 "open" issues. The issue is that today, you can't just drop in a component into a Zend Framework site... you'd have to manually copy files all over the tree and updating components is a nightmare. Yes, we could develop 50 different frameworks on top of ZFW (I just learned about Zym Engine yesterday even)... but thats just back to the balkanized world with huge diffusion of the userbase. An official solution would be faster and likely to pick up more total community input (even if all the other subframeworks were added together) There is a lot to be said about official/centralized solutions. It could also help Zend monetize parts of the framework and maybe get some more developers on the Zend team. For example EZ-Components seems to have a pretty solid business that leads to a lot of open-source contribution.If Zend wants to do it, that's cool too, but I don't think this should be another burden for the developers - neither Matthew or Ralph, nor any of the component leads from the community. $0.02 as usual. K |
|
|
On Tue, Jun 1, 2010 at 6:23 PM, Kevin McArthur <[hidden email]> wrote:
> > till wrote: > > > > (...) > 2. Config.ini taking over. > > I really hate the current config.ini usage for core components. What should > be a single point of configuration (ie the bootstrap) is turning into a web > of mess when debugging -- worse, it doesn't work at all with code completion > options, and it makes the framework a helluv a lot harder to debug/learn. > The current roadmap for 2.0 seems to send us further down this rabbit hole. > > > I disagree on the single configuration issue. > > That may make it easier for people to adopt and learn the framework - > on the other hand it makes it harder for those of us who actually only > use certain components - or not MVC, or not Zend_Application. All this > zero conf/automation stuff is also expensive in terms of runtime. I > don't want to create and setup Zend_Application if all I want is to > use Zend_Http_Client. > > Generally, I prefer a common way to configure components - e.g. all > components are configured with Zend_Config_Foo, or with something > else. I wouldn't offer five different ways. > > If I misunderstood your issue, let me know. > > > > I'm actually arguing _against_ the config.ini approach. I much prefer the > old-style bootstrapping. One point of responsibility. Ah, well - what can I say. :D For me, it wasn't clear if you mean a Zend_Config_Ini that's for example injected via __construct() or setConfig() or do you mean the global Zend_Application approach? > (...) > 14. PDF and document generation. (Third party integration) > > There are huge advances over the Zend Framework available in other libraries > (full disclosure, Willie Alberty and I [both major contributors to the > original PDF lib] forked the ZF lib into a new PDF project) but those > libraries require much more flexibility than the current testing/coding > standards require. The community needs to decide how external libraries will > be integrated with the ZF, and on what policy principles collaboration with > the other projects will work. I'm not advocating for inclusion of this lib, > but the same issues apply to dojo, to gdata, to amf... etc. Which brings me > to > > > Generally - I get the notion (and correct me if I'm wrong) that ZF > should be turned into this 3rd-party-library-agnostic "thing" that > integrates with whatever. I think that's not going to happen, at least > not from a plugin and play perspective. I don't think that should be a > goal on the roadmap either. > > If you want to see a pretty successful model, I suggest you check out > Rediska which is a library for Redis. Rediska ships with a driver for > Zend_Session and Zend_Cache (and possibly others) already and if > someone decides to write a driver for Cake or Symfony - well, that's > the responsibility of the Rediska project and not really an issue for > Symfony or Cake. > > More info here: http://rediska.geometria-lab.net/ > > There's really nothing wrong with integrating 3rd party libraries - > just like a couple people are working on a tighter integration with > Doctrine. If people would like something "in" ZF, they should work on > it. If however the idea is to make ZF compatible with everything out > there, development will drift away from core issues - as you mentioned > yourself already. > > > Ok, so what I was referring to here is that some components play by one set > of rules (full Zend process) and others by the rules of a third party. What > is the policy to decide on including third party components or a Zend > Framework port. Demand from the community. > As for Gdata, dojo, etc. - JavaScripting, that seems to be covered > already since there is an integration for jQuery in ZendX. And in > regard to Gdata. I think Zend either needs to go out with Google for > beers more often or they need to hire someone to take care of this > component. It seems to require a lot of time to keep up with the > development - maybe more than your average API. > > When I looked at Zend_Gdata a couple months ago, I thought it would be > better to drop it from core to ZendX. Let alone all the basic coding > issues that seem to have been overlooked in order to get it in (no > offense meant). > > The bottom line from all my yapping: I think it doesn't help the > framework to carry on all those extra components that look great for a > press release but are really ridden with issues to the max. Gdata > would be my example - over a 100 "open" issues. > > > In general I agree that these components bloat the framework. That said, > they exist and there should be policy for how/when this type of thing > occurs. Just to be clear and with no offense, I'm not after saving disk spacing. I'm more after maintenance cycles. I think if a component is not maintained it could be archived so people can get it if they are using it and don't fall short. > 15. App marketplace, phar, componentization. > > This is a huge thing missing from the Zend Marketplace. A way to share [and > sell] third party libraries for Zend Framework. Everyone has a cool set of > extensions, but very few are within the scope of the framwork itself. I'd > like to see a place where you could go get objects for a shopping cart, or a > blog, or whatever other pre-packaged type of thing will work with your > project. This doesn't have to be the exclusive domain of the CMS's. > > > With no offense, but I think this is more or less your own business. > ;-) And I think this shouldn't be on the framework roadmap either. > > If anyone - e.g. you - wants to step up they can do that. > > > The issue is that today, you can't just drop in a component into a Zend > Framework site... you'd have to manually copy files all over the tree and > updating components is a nightmare. Yes, we could develop 50 different > frameworks on top of ZFW (I just learned about Zym Engine yesterday even)... > but thats just back to the balkanized world with huge diffusion of the > userbase. An official solution would be faster and likely to pick up more > total community input (even if all the other subframeworks were added > together) "At work" we add new features as modules - always. They bootstrap themselves and I include them via svn:externals currently in app/modules. I'm pretty sure it can be done. I agree that a general solution needs to be found though so it's maybe easier for people to develop add ons, or like full-featured micro sites (or whatever you want to call them). > There is a lot to be said about official/centralized solutions. It could > also help Zend monetize parts of the framework and maybe get some more > developers on the Zend team. For example EZ-Components seems to have a > pretty solid business that leads to a lot of open-source contribution. Since most of the maintainers have left ez Systems, the components are currently relaunching as Zeta - independent of the company. Last time I checked they were trying to get into the incubator. Till |
|
In reply to this post by Kevin McArthur-2
On 1 Jun 2010, at 17:23, Kevin McArthur wrote: Just to interdict here a moment.. the config.ini approach which is current, is only due to the use of Zend_Application. There was suggestion of using a unified constructor, which would have allowed all components to be configured either by an array, or by a config object. (though I think this idea was shot down) which would have actually provided what you are asking for here. I don't see that the current configuration through a central config file actually has anything to do with this, as it is not even touched by those components, and is meerly used by the application resource plugins. That said, where we do have the unified bootstrapping of Zend_Application, these resource plugins allowing you to use a single config rather than a dozen separate ones, also provides an excellent central config for an application. So I guess what im saying here is.. revive the unified constructor idea, and that the current single config approach is actually a completely separate concern.
I don't see components like these are a problem for any framework, as long as they are kept maintained. The argument of bloating the framework is kind of a bad point... its a framework, its supposed to be providing resources such as these to make your life as a developer easier. These components should only be dropped if nobody gets their hands dirty and maintains them. To loose anything which is useful would be a real shame. Given the talk of a new packaging process, any argument for dropping things simply due to bloat should be out of the window. However in reference to your earlier comment about ExtJS, I dont think that particular library should even be entertained. its not shipped with a compatible license, and its licensing structure is such that many developers are actually not producing licensed code. ExtJS is *not* a free library to use if you take any money for your final application, while that is the case, nothing of this sort should be entertained for integration!
As discussed in IRC, this surmounts to an application framework. If I had wanted to be using an application framework, I wouldnt be using ZF right now, I'd be using Joomla or Drupal, or even perhaps Zym Engine. When the framework starts providing drop in applications, it looses its flexibility, because you will always need to be working to a strict application architecture to enable the use of these things. The way things stand, its not really all that hard to produce a self contained module, which most people would be able to use simply by adding to their views, for a component library *that* is enough!
|
Re: Community Input 2.0 - One thing at a Time. (Was: A response to the community)
|
In reply to this post by Kevin McArthur-2
... >> Generally, I prefer a common way to configure components - e.g. all >> components are configured with Zend_Config_Foo, or with something >> else. I wouldn't offer five different ways. >> >> If I misunderstood your issue, let me know. >> >> > I'm actually arguing _against_ the config.ini approach. I much prefer > the old-style bootstrapping. One point of responsibility. You are free to use the old style of bootstrapping. Zend_Application, is simply a convenience and consistency layer. Everything Zend_Application does, you can do by hand, just as you did before, inside a bootstrap.php file. There was a need to make the bootstrap process more object-oriented, and thus, more resuable and pluggable. That is why Zend_Application was born. > > Ok, so what I was referring to here is that some components play by one > set of rules (full Zend process) and others by the rules of a third > party. What is the policy to decide on including third party components > or a Zend Framework port. There should never be a real need to "port" Zend Framework. If there is, then we've not done a good job of creating an API that is ultimately extensible. (By "port", I mean forking a project and maintaining other functionality through the use of patches instead of object-oriented practices like "extends" and dependency injection. If we have an opportunity at 2.0 time to create more extensible API's for specific components, this should be top priority. > In general I agree that these components bloat the framework. That said, > they exist and there should be policy for how/when this type of thing > occurs. We will be looking at partitioning the framework into specializations or packages; perhaps with PEAR. People have have periodically asked for a-la-carte packaging, so, with 2.0- we'll have a look at that and try to get some proposals out there. >>> 15. App marketplace, phar, componentization. >>> >>> This is a huge thing missing from the Zend Marketplace. A way to share [and >>> sell] third party libraries for Zend Framework. Everyone has a cool set of >>> extensions, but very few are within the scope of the framwork itself. I'd >>> like to see a place where you could go get objects for a shopping cart, or a >>> blog, or whatever other pre-packaged type of thing will work with your >>> project. This doesn't have to be the exclusive domain of the CMS's. >>> >> >> With no offense, but I think this is more or less your own business. >> ;-) And I think this shouldn't be on the framework roadmap either. >> >> If anyone - e.g. you - wants to step up they can do that. I don't think the perspective of ZF was to ever produce final products like a CMS or Shopping Cart, but to provide a library of code to act as a foundation for those that wanted to. A library of code is hard enough to maintain and keep fresh, and the baggage that comes along from maintaining a "full software product" would surely sink the ship. Like till said, the community is free to pick up there. > The issue is that today, you can't just drop in a component into a Zend > Framework site... you'd have to manually copy files all over the tree > and updating components is a nightmare. Yes, we could develop 50 > different frameworks on top of ZFW (I just learned about Zym Engine > yesterday even)... but thats just back to the balkanized world with huge > diffusion of the userbase. An official solution would be faster and > likely to pick up more total community input (even if all the other > subframeworks were added together) That sounds like the kind of tight coupling that we are attempting to avoid. This type of tight coupling is what you'd expect to see in a full product like wordpress, drupal, or expression engine: where the mere presence of a file/"plugin" hooks into an existing, finalized and tightly coupled system. It sounds like you want to standardize on a CMS that is built on top of ZF, that has known "feature plugins and extensions" that can automatically hook into the system. I'm actually waiting for this product too in all honesty. I'd love to see a best practices CMS and shopping cart that is made for developers ;) -ralph |
Re: Community Input 2.0 - One thing at a Time. (Was: A response to the community)
|
On 06/01/2010 09:21 PM, Ralph Schindler wrote:
> > ... > >>> Generally, I prefer a common way to configure components - e.g. all >>> components are configured with Zend_Config_Foo, or with something >>> else. I wouldn't offer five different ways. >>> >>> If I misunderstood your issue, let me know. >>> >> I'm actually arguing _against_ the config.ini approach. I much prefer >> the old-style bootstrapping. One point of responsibility. > > You are free to use the old style of bootstrapping. Zend_Application, > is simply a convenience and consistency layer. Everything > Zend_Application does, you can do by hand, just as you did before, > inside a bootstrap.php file. > > There was a need to make the bootstrap process more object-oriented, > and thus, more resuable and pluggable. That is why Zend_Application > was born. It allowed developers to have a common way to bootstrap 99% of their applications - I am pretty sure, that before Zend_Application was included, most developers have their own bootstrap files that delivered quite similar functionality. At least all the code I have seen, was very easily ported to Zend_Application - since it already was similarly designed. With current design, it is actually up to you whether you want a single config file or several. You can have your routes separated into different file, and make sure you bootstrap resource accordingly. I guess I am missing sth, as I don't see the real issues with current design. -- Victor Farazdagi Blog | http://www.phpmag.ru UMapper | http://www.umapper.com |
Re: Community Input 2.0 - One thing at a Time. (Was: A response to the community)
|
|
In reply to this post by Ralph Schindler-2
Replies Inline:
> > You are free to use the old style of bootstrapping. Zend_Application, > is simply a convenience and consistency layer. Everything > Zend_Application does, you can do by hand, just as you did before, > inside a bootstrap.php file. > > There was a need to make the bootstrap process more object-oriented, > and thus, more resuable and pluggable. That is why Zend_Application > was born. > > things. It's become confusing and difficult to debug. Not a day goes by where I don't see new zf dev's trying to figure out what config keys do/dont exist etc... Might be a docs problem, but more I think its a division of configuration responsibility. I don't have all the answers, but I think the community needs to reconsider what configuration is in ZF. Somewhere the line between programming and config got blurred.. (eg bootstrapping routes or layouts from a config.ini... etc) >> >> Ok, so what I was referring to here is that some components play by >> one set of rules (full Zend process) and others by the rules of a >> third party. What is the policy to decide on including third party >> components or a Zend Framework port. > > There should never be a real need to "port" Zend Framework. If there > is, then we've not done a good job of creating an API that is > ultimately extensible. (By "port", I mean forking a project and > maintaining other functionality through the use of patches instead of > object-oriented practices like "extends" and dependency injection. > > If we have an opportunity at 2.0 time to create more extensible API's > for specific components, this should be top priority. I'm referring to bringing other projects IN to the ZF. Eg dojo is largely added as-is... whereas other components have been fully adapted to Zend coding standards. There's a decision made each time about inclusion of third-party as-is or conforming to the API (tests,docs,process,etc)... > > >> In general I agree that these components bloat the framework. That >> said, they exist and there should be policy for how/when this type of >> thing occurs. > > We will be looking at partitioning the framework into specializations > or packages; perhaps with PEAR. People have have periodically asked > for a-la-carte packaging, so, with 2.0- we'll have a look at that and > try to get some proposals out there. I'd vote against pear... it doesn't handle multiple installed versions very well. > > > I don't think the perspective of ZF was to ever produce final products > like a CMS or Shopping Cart, but to provide a library of code to act > as a foundation for those that wanted to. A library of code is hard > enough to maintain and keep fresh, and the baggage that comes along > from maintaining a "full software product" would surely sink the ship. > > Like till said, the community is free to pick up there. I'm not arguing for a full CMS (with point and click UI's for config/dbsetup/common architecture for layouts or admin pages, etc...) what I'm saying is the feature that allows code reuse in these CMS's is largely distinct from the rigidity that makes them a CMS. I don't want Zend to include a shopping cart, but i want to be able to say to _anyone_ running a ZF site... hey i've got this one packaged over here, you drop it in your lib, add it to your bootstrap and here's where you override the default functionality/add overriding views. (I'm thinking like a way to override a lot of partials). We have all the features in ZF now, there's just no common api. A phar plugin format would go a long way towards making this 'just work'. > > That sounds like the kind of tight coupling that we are attempting to > avoid. This type of tight coupling is what you'd expect to see in a > full product like wordpress, drupal, or expression engine: where the > mere presence of a file/"plugin" hooks into an existing, finalized and > tightly coupled system. I'm thinking theres a nice middle ground. Like modules, but that actually work along the entire system. > > It sounds like you want to standardize on a CMS that is built on top > of ZF, that has known "feature plugins and extensions" that can > automatically hook into the system. I'm saying the core system should be easily integrated with -- and that we should develop some sets of best practices that allow code re-use and interop. The current state of the re-use ecosystem is really, very very poor. > > I'm actually waiting for this product too in all honesty. I'd love to > see a best practices CMS and shopping cart that is made for developers ;) I'd like to see this CMS built on top of the type of core i'm talking about as well... but its a separate product on top. The downsides of a full blown CMS don't necessarily preclude the benefits of component libraries and code reuse. K |
Re: Community Input 2.0 - One thing at a Time. (Was: A response to the community)
|
Comments inline
Am 01.06.2010 19:36, schrieb Kevin McArthur: > Replies Inline: >> >> You are free to use the old style of bootstrapping. >> Zend_Application, is simply a convenience and consistency layer. >> Everything Zend_Application does, you can do by hand, just as you did >> before, inside a bootstrap.php file. >> >> There was a need to make the bootstrap process more object-oriented, >> and thus, more resuable and pluggable. That is why Zend_Application >> was born. >> >> > As a convenience, its now to the point where theres two ways to do > things. It's become confusing and difficult to debug. Not a day goes > by where I don't see new zf dev's trying to figure out what config > keys do/dont exist etc... Might be a docs problem, but more I think > its a division of configuration responsibility. I don't have all the > answers, but I think the community needs to reconsider what > configuration is in ZF. Somewhere the line between programming and > config got blurred.. (eg bootstrapping routes or layouts from a > config.ini... etc) which possibilities are open. More than one way is the real way live... > >>> >>> Ok, so what I was referring to here is that some components play by >>> one set of rules (full Zend process) and others by the rules of a >>> third party. What is the policy to decide on including third party >>> components or a Zend Framework port. >> >> There should never be a real need to "port" Zend Framework. If there >> is, then we've not done a good job of creating an API that is >> ultimately extensible. (By "port", I mean forking a project and >> maintaining other functionality through the use of patches instead of >> object-oriented practices like "extends" and dependency injection. >> >> If we have an opportunity at 2.0 time to create more extensible API's >> for specific components, this should be top priority. > > I'm referring to bringing other projects IN to the ZF. Eg dojo is > largely added as-is... whereas other components have been fully > adapted to Zend coding standards. There's a decision made each time > about inclusion of third-party as-is or conforming to the API > (tests,docs,process,etc)... >> >> >>> In general I agree that these components bloat the framework. That >>> said, they exist and there should be policy for how/when this type >>> of thing occurs. >> >> We will be looking at partitioning the framework into specializations >> or packages; perhaps with PEAR. People have have periodically asked >> for a-la-carte packaging, so, with 2.0- we'll have a look at that and >> try to get some proposals out there. > > I'd vote against pear... it doesn't handle multiple installed versions > very well. like to use the Zend_Form vers. 1.0 and the Zend_Registry vers. 0.4 (when act as PEAR packages) >> >> >> I don't think the perspective of ZF was to ever produce final >> products like a CMS or Shopping Cart, but to provide a library of >> code to act as a foundation for those that wanted to. A library of >> code is hard enough to maintain and keep fresh, and the baggage that >> comes along from maintaining a "full software product" would surely >> sink the ship. >> >> Like till said, the community is free to pick up there. > I'm not arguing for a full CMS (with point and click UI's for > config/dbsetup/common architecture for layouts or admin pages, etc...) > what I'm saying is the feature that allows code reuse in these CMS's > is largely distinct from the rigidity that makes them a CMS. I don't > want Zend to include a shopping cart, but i want to be able to say to > _anyone_ running a ZF site... hey i've got this one packaged over > here, you drop it in your lib, add it to your bootstrap and here's > where you override the default functionality/add overriding views. > (I'm thinking like a way to override a lot of partials). > > We have all the features in ZF now, there's just no common api. A phar > plugin format would go a long way towards making this 'just work'. > >> >> That sounds like the kind of tight coupling that we are attempting to >> avoid. This type of tight coupling is what you'd expect to see in a >> full product like wordpress, drupal, or expression engine: where the >> mere presence of a file/"plugin" hooks into an existing, finalized >> and tightly coupled system. > I'm thinking theres a nice middle ground. Like modules, but that > actually work along the entire system. >> >> It sounds like you want to standardize on a CMS that is built on top >> of ZF, that has known "feature plugins and extensions" that can >> automatically hook into the system. > I'm saying the core system should be easily integrated with -- and > that we should develop some sets of best practices that allow code > re-use and interop. The current state of the re-use ecosystem is > really, very very poor. >> >> I'm actually waiting for this product too in all honesty. I'd love >> to see a best practices CMS and shopping cart that is made for >> developers ;) > I'd like to see this CMS built on top of the type of core i'm talking > about as well... but its a separate product on top. The downsides of a > full blown CMS don't necessarily preclude the benefits of component > libraries and code reuse. > > K > > > |
|
In reply to this post by Kevin McArthur-2
>Since there doesn't seem to be any interest by Zend in the community having much, if any, ownership over 2.0's
>architecture. Lets look some of the issues one-by-one, and I think it will highlight where the issue is with >letting Zend prototype everything. The community can have a field day once the core stuff is let out. As has been said before. As has also been said before, the community showed close to zero interest in 2.0's architecture for most of the past year that Matthew has been very publicly talking, writing and developing around. I still haven't figured out what the community is upset with, that Matthew/Ralph are doing something behind closed doors (for now - and with at least some community support), or that the community completely missed every single opportunity over the space of a year to actually contribute. To be perfectly honest, I'm finding similar statements pretty tiresome since, from what I've read, they're not grounded anywhere even remotely close to reality. >1. Post-Redirect-Get tight integration for forms. > >This has been brought up time and again, and its pretty clear its not on the roadmap for 2.0. To do a component >like this justice it needs links to Session, FlashMessenger, Forms, Filters/Validators, Database, etc.. its an >architectural issue which is difficult to implement in an elegant way in the current framework. There's a proposal wiki for anyone wishing to hatch plans to improve the situation. Outside the wiki, some in-depth analysis of the problem and a proposed solution could probably go a long way. >2. Config.ini taking over. > >I really hate the current config.ini usage for core components. What should be a single point of configuration (ie >the bootstrap) is turning into a web of mess when debugging -- worse, it doesn't work at all with code completion >options, and it makes the framework a helluv a lot harder to debug/learn. The current roadmap for 2.0 seems to >send us further down this rabbit hole. We need to have some sort of core configuration approach. The current one may not be the single best approach, but it's the one that was written and works. It's also entirely optional. >3. Will Auth/ACL become a core concept in the dispatcher? > >There are a lot of benefits to getting this out of the current dispatcher flag cycling. > >4. Context's. Mobile, Json, Language, etc. > >Is this the right way to handle different contexts. Since a lot of these questions need to be answered by >decisions on the accept header, on the user agent, etc these types of dispatches could probably be tightly >integrated with the front controller rather than as an add-on after the fact. I agree here ;). >5. ORM integration. Zend_Db. > >Massive changes are needed here. Is Doctrine the solution, or just more api inconsistency? How will it be >integrated? Doctrine is too popular to ignore. Integration kind of depends on approach, most of us are probably already using fairly simplistic integration methods that just worry about configuration and model loading. It's hard to compare it with Zend_Db - both are just completely different. Zend_Db is not an ORM, and never will be. It's great for less demanding situations that don't need a ton of complexity, and I do hope we're not losing it. >6. *Helper patterns. > >Have they proved useful or detrimental. Can their impact on performance be analyzed? Example? >7. Action Stacking. > >Major architectural issue here. Current solution was discontinued because it sucked. Can this concept be done >correctly so that we develop small actions that have specific responsibility. Action stacking means making multiple Controller calls. It's an obvious code smell for refactoring - the controller should NOT contain domain logic. Other frameworks have tried to get around this by using Controller-like alternatives that need far less dispatch/etc processing with varying results. At the end of the day, they are what they are - bad design. This isn't a framework concern (outside the extent to which its supported) since their use is determined by the application not the framework. >8. Layout/Composition > >Zend_Layout is great, but it needs a _lot_ more if it's to provide a solid and consistent foundation capable of >competing with CMS products in the market. I realize ZF isn't a CMS, but standard regions for NAV, Headers, >Footers, Content, etc... along with standard ways to inject content into this system would be a big improvement >over the current partial and placeholder infrastructure. (Ever tried tracking down where a placeholder got _all_ >of its content from in a complex application that has both views and controllers adding to placeholders... its >almost impossible) Can you clarify how this would be different from a specialised placeholder? (That's the assumption that will be made - a specialised placeholder). Pretty sure that's not the assumption you're relying on though. >11. Privacy and data tainting. > >The framework currently has no ingrained idea of data tainting. I think this should change, and was simply >waiting until the 2.0 architectural discussion was started to propose some major changes in how we handle data >moving throughout the framework. This is a key element to doing privacy assertions in multi-user environments. Would be nice to have but the last time it came up (way back when), the debate kept shifting back to such an approach making stuff too complicated. Not sure if attitudes have changed at all since then. >13. HTML5 + EXTJS + jqtouch and other UI-model altering development. > >Does the current view helper approach make sense in RIA environment. What are we leaving on the table for other >frameworks? Jqtouch is absolutely amazing, but its very hard to work with in the current zf model. As is ext-js, >etc... I'd like to see architectural consideration in light of the fact that the development world is no longer >page-view-centric. This goes back to my earlier item about actionstacking, contexts, etc. It should probably be discussed, but I'm not convinced it's a question of either/or. View Helpers are still useful for obvious reasons (and not everything has gone the RIA route). >14. PDF and document generation. (Third party integration) > >There are huge advances over the Zend Framework available in other libraries (full disclosure, Willie Alberty and >I [both major contributors to the original PDF lib] forked the ZF lib into a new PDF project) but those libraries >require much more flexibility than the current testing/coding standards require. The community needs to decide >how external libraries will be integrated with the ZF, and on what policy principles collaboration with the other >projects will work. I'm not advocating for inclusion of this lib, but the same issues apply to dojo, to gdata, to >amf... etc. Which brings me to Isn't the question IF third party libraries may be integrated? The current integrations are largely outside of the community's control. They have a separate identity to a degree which discourages involvement for fear of interfering with whatever anonymous people are responsible for them. I think we can, and should, integrate where it makes sense. If that means a certain loosening of our coding standard and testing requirements, so be it - just so long as its a reasonable departure. I would be interesting in what kind of flexibility you have in mind. Just don't mention code coverage - maybe I'm alone in thinking CC is perhaps at the edge of being completely worthless. >I could go on... but thats enough to stir the pot towards, and underline why we need both comprehensive community >ARCHITECTURAL considerations and CODE LEVEL integration as well. Matthew cannot possibly solve all these points >on his own. Nor can he solve the other 50 that aren't mentioned. ZF needs the community steering the direction of >these features. It needs COMMUNITY OWNERSHIP over the project's path forward. I probably hinted at it in places, but there is always a flaw in these kinds of community rebellions (ye rebels!). They either take the reigns and do something, or they end up debating themselves into oblivion. So far, the community has veered towards oblivion. There has been progress in sorting out responsibilities for existing components, which is encouraging, but getting headway into major architectural changes needs a lot more effort. It needs a stubborn sort of protracted campaign with some sort of plan. At the moment, I'm seeing lots of people identify problems and hint at things to consider, but I'm still waiting for someone to actually show up with Solution #1 to discuss. This email is another small step in the right direction (for all I may have bluntly spoken against some of it ;)). Putting it another way, let's say we decide right now that we're damn well going to allow integration/inclusion of external libraries. Final. Anyone who refuses will be silently "removed" in a back alley at the weekend. There's one simple goal you mentioned. So, how do we effect it? What will it take to convince everyone else (who steered clear of any dark alleys)? How exactly does that decision get made? Do we need to campaign for it? Stalk this place in Vermont where a certain guy lives until he crumbles under the pressure? I don't have all (or even many) of the answers - it would be great to know the community could actually piece together those answers so everyone who's running around has somewhere to run at. http://blog.astrumfutura.com http://www.survivethedeepend.com OpenID Europe Foundation Irish Representative From: Kevin McArthur <[hidden email]> To: [hidden email] Cc: [hidden email] Sent: Tue, June 1, 2010 5:23:22 PM Subject: Re: [zf-contributors] Community Input 2.0 - One thing at a Time. (Was: A response to the community) till wrote: I'm actually arguing _against_ the config.ini approach. I much prefer the old-style bootstrapping. One point of responsibility.(...) (...) Ok, so what I was referring to here is that some components play by one set of rules (full Zend process) and others by the rules of a third party. What is the policy to decide on including third party components or a Zend Framework port. In general I agree that these components bloat the framework. That said, they exist and there should be policy for how/when this type of thing occurs.As for Gdata, dojo, etc. - JavaScripting, that seems to be covered The issue is that today, you can't just drop in a component into a Zend Framework site... you'd have to manually copy files all over the tree and updating components is a nightmare. Yes, we could develop 50 different frameworks on top of ZFW (I just learned about Zym Engine yesterday even)... but thats just back to the balkanized world with huge diffusion of the userbase. An official solution would be faster and likely to pick up more total community input (even if all the other subframeworks were added together)15. App marketplace, phar, componentization. There is a lot to be said about official/centralized solutions. It could also help Zend monetize parts of the framework and maybe get some more developers on the Zend team. For example EZ-Components seems to have a pretty solid business that leads to a lot of open-source contribution.If Zend wants to do it, that's cool too, but I don't think this should $0.02 as usual. K |
Re: Community Input 2.0 - One thing at a Time. (Was: A response to the community)
|
|
In reply to this post by Carlos Medina
> ->The idea of PEAR is not bad at all. I think it would be something > like to use the Zend_Form vers. 1.0 and the Zend_Registry vers. 0.4 > (when act as PEAR packages) This situation (among others) is exactly why we haven't done PEAR by component yet. I think it's generally a BAD idea to mismatch versions like that, ie Zend_Form from 1.10 with some other component in 1.5. This creates massive amounts of support overhead. I would think that from a technical standpoint, each component would have a hard dependency on another component of the exact same version. This means that if you are using any ZF components, they should all be part of the same version. As for Kevins comment: > > I'd vote against pear... it doesn't handle multiple installed versions very well. If you are attempting to run multiple versions of ZF, PEAR is not the ecosystem to use for that. Simple SVN or just installing packages would do fine. In fact, Zend_Loader can already handle multiple ZF's on the same system and outside of the standard include_path with relative ease. -ralph |
Re: Community Input 2.0 - One thing at a Time. (Was: A response to the community)
|
|
Ralph Schindler wrote:
> >> ->The idea of PEAR is not bad at all. I think it would be something >> like to use the Zend_Form vers. 1.0 and the Zend_Registry vers. 0.4 >> (when act as PEAR packages) > > This situation (among others) is exactly why we haven't done PEAR by > component yet. I think it's generally a BAD idea to mismatch versions > like that, ie Zend_Form from 1.10 with some other component in 1.5. > > This creates massive amounts of support overhead. I would think that > from a technical standpoint, each component would have a hard > dependency on another component of the exact same version. This means > that if you are using any ZF components, they should all be part of > the same version. > > As for Kevins comment: > >> >> I'd vote against pear... it doesn't handle multiple installed >> versions very well. > > If you are attempting to run multiple versions of ZF, PEAR is not the > ecosystem to use for that. Which is why its not something I'd like to see as the default packaging. I cant ever see a scenario where I would trust a new release of ZF enough to just pear update on it and _hope_ all of my sites take to the upgrade well. Lots of ZF versions, for all the BC compatibility effort, still require some sort of trivial action on each upgrade. System wide in-place upgrading is a path to disaster for ZFW. > Simple SVN or just installing packages would do fine. I use a common set of libraries in /usr/share/php/ZendFramework/[ZendFramework-1.10.4] .... just drop-in and install each new version there... let the sites pick which version to pick-up... then you can upgrade the versions at the same time as you test the site. Keeps the site svn's small, and reduces the dependency on svn:externals. > > In fact, Zend_Loader can already handle multiple ZF's on the same > system and outside of the standard include_path with relative ease. Working well, but as Zend_Tool comes in to play, need to decide how to handle components in a versioned way. (Though I do agree that we should enforce a same-version-between-components policy.) K |
Re: Community Input 2.0 - One thing at a Time. (Was: A response to the community)
|
In reply to this post by Ralph Schindler-2
>> ->The idea of PEAR is not bad at all. I think it would be something >> like to use the Zend_Form vers. 1.0 and the Zend_Registry vers. 0.4 >> (when act as PEAR packages) > > This situation (among others) is exactly why we haven't done PEAR by > component yet. I think it's generally a BAD idea to mismatch versions > like that, ie Zend_Form from 1.10 with some other component in 1.5. > > This creates massive amounts of support overhead. I would think that > from a technical standpoint, each component would have a hard > dependency on another component of the exact same version. This means > that if you are using any ZF components, they should all be part of > the same version. up to minor versions isn't a good solution. Only an idea: A ZF mini release have to be full backward compatible. Therefore we could say a mini version is based by component and the minor & major versions are based of the complete framework. ZF v1.10.x -> Zend_View 1.10.1 -> Zend_Amf 1.10.12 -> Zend_Version::VERSION = '1.10' ... Marc |
Re: Community Input 2.0 - One thing at a Time. (Was: A response to the community)
|
Well, there shouldn't be any difference between mini version except for
bug fixes. So why wouldn't you use the latest mini version of each component anyways then? -- Best Regards, Pieter Kokx PHP Developer Zend Framework developer On 01-06-10 23:38, Marc Bennewitz wrote: > >>> ->The idea of PEAR is not bad at all. I think it would be something >>> like to use the Zend_Form vers. 1.0 and the Zend_Registry vers. 0.4 >>> (when act as PEAR packages) >>> >> This situation (among others) is exactly why we haven't done PEAR by >> component yet. I think it's generally a BAD idea to mismatch versions >> like that, ie Zend_Form from 1.10 with some other component in 1.5. >> >> This creates massive amounts of support overhead. I would think that >> from a technical standpoint, each component would have a hard >> dependency on another component of the exact same version. This means >> that if you are using any ZF components, they should all be part of >> the same version. >> > I like the pear way of splitting components too but a version mismatch > up to minor versions isn't a good solution. > Only an idea: > A ZF mini release have to be full backward compatible. Therefore we > could say a mini version is based by component and the minor & major > versions are based of the complete framework. > > ZF v1.10.x > -> Zend_View 1.10.1 > -> Zend_Amf 1.10.12 > -> Zend_Version::VERSION = '1.10' > ... > > Marc > > > |
Re: Community Input 2.0 - One thing at a Time. (Was: A response to the community)
Administrator
|
In reply to this post by Ralph Schindler-2
-- Ralph Schindler <[hidden email]> wrote
(on Tuesday, 01 June 2010, 03:59 PM -0500): > As for Kevins comment: > > I'd vote against pear... it doesn't handle multiple installed > > versions very well. > > If you are attempting to run multiple versions of ZF, PEAR is not > the ecosystem to use for that. Simple SVN or just installing > packages would do fine. Actually, Pyrus (the PEAR2 installer) can handle parallel installations of different versions of a component. Additionally, we would version all components at the same time -- if you install Zend\Queue-2.0.3, it's dependencies will all be on 2.0.3 components. This is relatively easy to do, and, IIRC, both Symfony and eZcomponents (now Zeta Components) have been doing exactly this to distribute their own projects. -- Matthew Weier O'Phinney Project Lead | [hidden email] Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc |
Re: Community Input 2.0 - One thing at a Time. (Was: A response to the community)
|
|
In reply to this post by Pieter Kokx
> Well, there shouldn't be any difference between mini version except for > bug fixes. So why wouldn't you use the latest mini version of each > component anyways then? > 1. On splitting components like pear you have to know which component is dependents on which AND the components needs to be download alone. 2. A mini release doesn't change code / fix bugs on all components - than the mini version of components without changes doesn't need an update. > > > > On 01-06-10 23:38, Marc Bennewitz wrote: > >> >> >>>> ->The idea of PEAR is not bad at all. I think it would be something >>>> like to use the Zend_Form vers. 1.0 and the Zend_Registry vers. 0.4 >>>> (when act as PEAR packages) >>>> >>>> >>> This situation (among others) is exactly why we haven't done PEAR by >>> component yet. I think it's generally a BAD idea to mismatch versions >>> like that, ie Zend_Form from 1.10 with some other component in 1.5. >>> >>> This creates massive amounts of support overhead. I would think that >>> from a technical standpoint, each component would have a hard >>> dependency on another component of the exact same version. This means >>> that if you are using any ZF components, they should all be part of >>> the same version. >>> >>> >> I like the pear way of splitting components too but a version mismatch >> up to minor versions isn't a good solution. >> Only an idea: >> A ZF mini release have to be full backward compatible. Therefore we >> could say a mini version is based by component and the minor & major >> versions are based of the complete framework. >> >> ZF v1.10.x >> -> Zend_View 1.10.1 >> -> Zend_Amf 1.10.12 >> -> Zend_Version::VERSION = '1.10' >> ... >> >> Marc >> >> >> >> > > |
|
|
On Wed, Jun 2, 2010 at 12:05 AM, Marc Bennewitz <[hidden email]> wrote:
> >> Well, there shouldn't be any difference between mini version except for >> bug fixes. So why wouldn't you use the latest mini version of each >> component anyways then? >> > 1. On splitting components like pear you have to know which component is > dependents on which AND the components needs to be download alone. package.xml to the rescue. The installer takes care of the rest. > 2. A mini release doesn't change code / fix bugs on all components - > than the mini version of components without changes doesn't need an update. I agree, we wouldn't need to bump up versions if there are no changes. I also see no issues here. For people who download the complete releases/tree nothing will change. For people who consume through a PEAR channel, the installer (pyrus) takes care of all. And as Matthew said, pyrus supports multiple installations side by side as well. Pear(1) did too, but it's a lot more messy and less user-friendly. Till |
Re: Community Input 2.0 - One thing at a Time. (Was: A response to the community)
|
I've been following this thread for a while now. With regards to the most current topic which is the management of multiple versions of either the whole framework or individual components in the same environment, I'd like to play devils advocate and ask if there is really enough community demand to invest previous development, testing and documentation resources supporting this kind of installation. Might it be the case that the svn:externals or downloading the whole tar ball and deploying it with the project is "good enough" for those that need multiple versions?
-Josh Sent from my iPad On Jun 1, 2010, at 6:31 PM, till <[hidden email]> wrote: > On Wed, Jun 2, 2010 at 12:05 AM, Marc Bennewitz <[hidden email]> wrote: >> >>> Well, there shouldn't be any difference between mini version except for >>> bug fixes. So why wouldn't you use the latest mini version of each >>> component anyways then? >>> >> 1. On splitting components like pear you have to know which component is >> dependents on which AND the components needs to be download alone. > > package.xml to the rescue. The installer takes care of the rest. > >> 2. A mini release doesn't change code / fix bugs on all components - >> than the mini version of components without changes doesn't need an update. > > I agree, we wouldn't need to bump up versions if there are no changes. > I also see no issues here. > > For people who download the complete releases/tree nothing will > change. For people who consume through a PEAR channel, the installer > (pyrus) takes care of all. > > And as Matthew said, pyrus supports multiple installations side by > side as well. Pear(1) did too, but it's a lot more messy and less > user-friendly. > > Till |
Re: Community Input 2.0 - One thing at a Time. (Was: A response to the community)
|
|
Josh,
The issue is what happens when you pear upgrade, and every ZF site on the box breaks. ZF versions have never been BC enough for that kind of system wide upgrading. Its fairly common for an upgrade to have a minor regression, notice, or upgrade procedure. http://framework.zend.com/manual/en/migration.html for example. Nothing major if you're doing it on a site-by-site basis -- but upgrading in place == some major issues when running lots of sites. If pear2 can handle multiple versions in a way that wont result in a simple in place 'upgrade' but rather, 'install latest' activity. Then it should work fine. Kevin Josh Butts wrote: > I've been following this thread for a while now. With regards to the most current topic which is the management of multiple versions of either the whole framework or individual components in the same environment, I'd like to play devils advocate and ask if there is really enough community demand to invest previous development, testing and documentation resources supporting this kind of installation. Might it be the case that the svn:externals or downloading the whole tar ball and deploying it with the project is "good enough" for those that need multiple versions? > > -Josh > > Sent from my iPad > > On Jun 1, 2010, at 6:31 PM, till <[hidden email]> wrote: > > >> On Wed, Jun 2, 2010 at 12:05 AM, Marc Bennewitz <[hidden email]> wrote: >> >>>> Well, there shouldn't be any difference between mini version except for >>>> bug fixes. So why wouldn't you use the latest mini version of each >>>> component anyways then? >>>> >>>> >>> 1. On splitting components like pear you have to know which component is >>> dependents on which AND the components needs to be download alone. >>> >> package.xml to the rescue. The installer takes care of the rest. >> >> >>> 2. A mini release doesn't change code / fix bugs on all components - >>> than the mini version of components without changes doesn't need an update. >>> >> I agree, we wouldn't need to bump up versions if there are no changes. >> I also see no issues here. >> >> For people who download the complete releases/tree nothing will >> change. For people who consume through a PEAR channel, the installer >> (pyrus) takes care of all. >> >> And as Matthew said, pyrus supports multiple installations side by >> side as well. Pear(1) did too, but it's a lot more messy and less >> user-friendly. >> >> Till >> |
|
In reply to this post by Kevin McArthur-2
On 6/1/2010 7:36 PM, Kevin McArthur wrote:
>> We will be looking at partitioning the framework into specializations >> or packages; perhaps with PEAR. People have have periodically asked >> for a-la-carte packaging, so, with 2.0- we'll have a look at that and >> try to get some proposals out there. > > I'd vote against pear... it doesn't handle multiple installed versions > very well. To PEAR or not to PEAR is besides the point. Seperate packaging is the point. I have argued this before and I am a great supporter of splitting into separate "core" and "components". However that is distributed is not really that interesting an issue, since you could simply distribute it in many many forms. (PEAR, SVN, tarballs, git, rpm, deb, etc etc) In other words: Distribution and packaging are two different issues, and should be discussed as such. imho ;) drm / Gerard |
«
Return to ZF Contributor
|
1 view|%1 views
Loading...
| Powered by Nabble | Edit this page |