[Agavi-Users] Agavi is now on GitHub!

[Dominik del Bondio]

Hi everyone,

We're thrilled to announce the immediate availability of Agavi on GitHub!

We realize it took much longer than anybody, even ourselves, anticipated. But thanks
to the hard work of David, Noah and myself with the assistance of Steffen, Thorsten,
Tom and everybody else who provided their support, we finally did it!

A big thumbs up goes out to everyone out there for sticking around during that time
and not abandoning, what we think, is still one of the best PHP frameworks available
today.

The present state:

There are some immediate effects of the migration:
- Agavi is now installable via Composer.

- Any link to Trac will redirect to corresponding GitHub page. This should work for
most old Trac urls, including the wiki, browser and even changesets.
Anyone with existing credentials can still login at https://trac.agavi.org/login
and see the old content while being logged in.

- The Subversion repository will stay available for at least 6 months from now in
readonly mode. Any changes made to the Git repository will not be reflected in the
Subversion repository. For anyone using externals to specific releases we suggest
switching to the Subversion bridge on GitHub. For anyone using externals to a
specific revision please contact me off list so I can look up the right revision
for you to use on the GitHub Subversion bridge (That sadly isn't trivial and
can't be done with a simple mapping).

- The tickets and commits mailing lists will be closed. Please use GitHub
subscriptions as a replacement.

- Travis CI is set up and will test all commits.


Roadmap:

While this already is a major step forward, there is still more work to do to bring
Agavi back up to speed. These include:
- Many small improvements to the surrounding infrastructure (API docs generator
update, port documentation to Sphinx, etc)


We will start the 1.1 release cycle in 1-2 months from now. The current changelog is
available at https://github.com/agavi/agavi/blob/master/CHANGELOG and we should be
able to bring even more goodies into the release, including a much better
authorization and ACL support, and support for ext/intl in the i18n module.

After 1.1 there will be at least one more minor release. Please check
https://github.com/agavi/agavi/issues?milestone=22&state=open for list of planned
features. The last 1.x release will be a long term support (LTS) release, which
we plan to support for at least 18 months.
The plan for 2.0 is not yet finalized but it will be a mostly incremental update
with some necessary breaking changes. This includes moving everything to namespaces
and cleanup of a few unsound spots in the code.

Right now we haven't completely figured out the new development model for
branching and pull requests for permanent contributors.

Until we figured the best development model, we invite everyone to start creating
pull requests for master! We will then make sure it ends up in the next bugfix or
minor release, whichever is applicable.

For us, the move to GitHub is just the beginning – we have many plans and ideas to
advance Agavi in the future. But we cannot do that without you.

Happy forking!

Dominik


_______________________________________________
users mailing list
us...@lists.agavi.org
http://lists.agavi.org/mailman/listinfo/users

[MugeSo]

Hi,

I'm glad to see this news!
We've long long long looked forward to this.

PHP(and its trend) has very evolution: PSR, composer, DI container,
trait, generator, closure, etc... during development of agavi freezed.
So, I think, there is many tasks to adapt to thoese things.

However, agavi reaped benefit of social coding now!!
Oh, we can fork and send pull request! yay!

Thanks a lot for effort of Dominik, David and Noah!

MugeSo

[Noah Fontes]

Congratulations! This has been an amazing effort- very well done. I think everyone will be impressed with the quality of the migration. And of course, a big thanks to Dominik for the effort he put in to get this out the door at last.

Looking forward to the future of Agavi development!

Best-

Noah

Agavi Announce Mailing List
anno...@lists.agavi.org
http://lists.agavi.org/mailman/listinfo/announce

[André Fiedler]

That's the best news so far this year. Thank you very much for your work! :o)


-----Ursprüngliche Nachricht-----
Von: users-...@lists.agavi.org [mailto:users-...@lists.agavi.org] Im Auftrag von Dominik del Bondio
Gesendet: Montag, 3. März 2014 18:26
An: anno...@lists.agavi.org
Cc: Agavi Dev Mailing List; Agavi Users Mailing List
Betreff: [Agavi-Users] Agavi is now on GitHub!

For us, the move to GitHub is just the beginning - we have many plans and ideas to advance Agavi in the future. But we cannot do that without you.

[Mike Seth]

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!

- A more abstract configuration backplane, so that configuration sources aren't necessarily XML

- A more general class loading and instantiation subframework encouraged for userspace code

- A forge-type repository of configuration, enhancements and plugins, and modules and submodules as a stronger abstraction

- 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

- Stronger native support for command line consoles

- Stronger native debugging facilities

- A more evolved logging system

- Framework-supplied cryptographic services

- Breakup of complex code pieces (e.g. routing and FPF) into something more manageable

- Removal of hacks that support legacy webservers and use of new PHP APIs

- Support for closures

- Support for event driven programming, particularly a subscriber-observer approach for the binding between the controller-view chain and the models

- PSRx compliance

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?

[Dominik del Bondio]

Hi,

to address your points individually:

PSR: i basicly only agree to PSR-0/4 and and PSR-3 such that we could provide a compatibility layer.
Composer: that's already implemented (see https://packagist.org/packages/agavi/agavi) and will come into effect with the next release.
There will be a 1.0.8 release in the near future. Until then i'd suggest using 1.0-dev for new projects. This is basicly 1.0.7 with
patches for failing tests and the composer integration
DI Container: Actually AgaviContext is a service locator. While this is may not be perfect changing everything to DI is something we need to discuss for 2.0
Traits: There are some great opportunities here to fix the AgaviParameterHolder and AgaviAttributeHolder coupling. But this is 2.0 stuff since that's a breaking change
Generators: i don't see much use for generators in the scope of Agavi right now.
Closures: yes please. Although there are not that many uses of callbacks right now in Agavi

So yes we will adapt to those things, but only for 2.0. And before that i'd like to get the stuff which is in the pipeline for 1.x out first

best regards,

Dominik

Am 03.03.2014 um 19:07 schrieb MugeSo <mug...@mugeso.com>:

> Hi,
>
> I'm glad to see this news!
> We've long long long looked forward to this.
>
> PHP(and its trend) has very evolution: PSR, composer, DI container, trait, generator, closure, etc... during development of agavi freezed.
> So, I think, there is many tasks to adapt to thoese things.
>
> However, agavi reaped benefit of social coding now!!
> Oh, we can fork and send pull request! yay!
>
> Thanks a lot for effort of Dominik, David and Noah!
>
> MugeSo
>
>

[Dominik del Bondio]

Hi Mike,

See my inline responses

Am 04.03.2014 um 09:52 schrieb Mike Seth <m...@mikeseth.com>:

> 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

[Niklas Närhinen]

Hello all.

For debugging purposes there is already ADT which is quite abandoned these days.

The source code can be found from https://github.com/nnarhinen/AgaviDebugTools

I don't use Agavi on daily basis anymore, but when I still was using it, it worked great for us.

It already has some of the discussed features:  SQL Query logging (for Propel ORM at least), Request parameter inspection (pre/post-validation) etc. Maybe you should look into to it at least first before doing all the job from scratch.

IIRC I did patch it to support Agavi 1.1 breaking global filters changes.

[Mike Seth]

How about this:

I will put together some rule-based code (I'm thinking Common Lisp would be good here) to patch the stable version for namespace support. We'll test it rigorously and iron out the kinks. Once the LTS version comes out, we can run the source through this processor, and then any necessary refactoring could be done. I've taken a brief look at the code base for this purpose before, the amount of manual effort to correctly convert the framework to namespaces is staggering. 

[Jan Schütze]

Hi Dominik,

sounds good to me!

Looking forward to some new stuff in agavi!

Do we want to use existing libraries for core tasks? For example
content negiotion can be done with this lib
http://williamdurand.fr/Negotiation/ . A memoize cache layer, can be
added with this https://github.com/doctrine/cache .

Regards

Jan

PS: For debugging purposes in agavi we use my
https://github.com/DracoBlue/PhpDebugToolbar for ages :)

--

http://dracoblue.net