Hi Mike, See my inline responses
Am 04.03.2014 um 09:52 schrieb Mike Seth <[email protected]>: > I am delighted by the news and eager to lend any assistance; Agavi 2.0 has > been my dream for a long, long time. Some of the things I would like to > implement, off the top of my head: > > - Namespaces, god, please! Not just namespaces, since this is 2.0 anyways i'd like to break many other things as well. Mainly fixing some really bad naming decision (like AgaviUser/AgaviStorage for session, etc) > - A more abstract configuration backplane, so that configuration sources > aren't necessarily XML You probably remember that we had support for multiple configuration formats back in the day. I think what we want today is a configuration system written to be used from PHP alone. And the XML configuration as a frontend to that system. Something which is largely related to the configuration system would be a general introspection module which could form the basis for a new build system and could be used for IDE integrations. > - A more general class loading and instantiation subframework encouraged for > userspace code You mean DI? Yeah, we definitly need something more generic than we have now > - A forge-type repository of configuration, enhancements and plugins, and > modules and submodules as a stronger abstraction I don't think we need a custom forge for that, providing a strong module/plugin system would be enough. Installing of modules could be done with composer then. > - Change in the builder and application structure that would allow MVC > components and other resources to be grouped by their logical relationship > instead of their component rank and otherwise customizable layouts I think Agavi should still provide a strong emphasis on how things should be organized. But i agree that the current layout is far from optimal > - Stronger native support for command line consoles agreed > - Stronger native debugging facilities Like a debug toolbar? Agreed! > - A more evolved logging system Even more evolved? I think the system we have now works quite well for general logging. Where we should improve is context specific logging (like slq statements, framework internals) which would be required for a great debug toolbar > - Framework-supplied cryptographic services Care to explain that one? > - Breakup of complex code pieces (e.g. routing and FPF) into something more > manageable Absolutely. For the routing that would be rather straightforward. The FPF on the other hand is probably pretty hard to do in an easier way. That definitly needs some evaluation. > - Removal of hacks that support legacy webservers and use of new PHP APIs I don't like the way we handle the webserver intricacies right now. This will need some major refactoring > - Support for closures > - Support for event driven programming, particularly a subscriber-observer > approach for the binding between the controller-view chain and the models This is something which needs some serious thought. I don't think we should base the framework itself on an event driven model (this makes the code really hard to follow/grasp) but rather provide defined insertion points for custom stuff. This also needs lots of discussion first > - PSRx compliance See my other mail for that ;) > My obvious question is, before any and all work is ever done: for 2.0, what > is preferable: refactoring the existing codebase? Rewriting from scratch? > Somewhere in the middle? I am leaning towards a refactoring approach. I think if the lay the right groundwork for 2.0 There are some more stuff which definitly need some overhaul, like the validation system, especially the configuration/array handling. My focus for now is the 1.x line. We need to finish all the stuff we have planned until 1.2. We can definitly discuss 2.0 stuff before then, but we shouldn't get lost in 2.0 stuff before 1.x is in the state we like it to have Kind regards Dominik _______________________________________________ users mailing list [email protected] http://lists.agavi.org/mailman/listinfo/users
