FIG you are doing it wrong

[Florin Patan]

Hi there FIG,

What's wrong with you?

The activities these days are about doing bylaws and PSRs refactorings.

I don't understand the need for a new PSR for autoloading, except to burden autoloaders again. The current proposal is missing a huge point, compatibility with PSR-0 and how to fallback from PSR-4 (it's clear that's the name for it) to PSR-0 then to other loaders. I would have expected more from folks from this group. But instead you want to discuss about doing bylaws and other random things because I think that FIG has done it's job, all the libraries/frameworks are finally inter-operable on a certain level and you need to do some stuff now to gain more  popularity by saying: hey, look, I'm the author of PSR-X which is just a refactoring of PSR-Y with some small changes but it's done by me. Or say: hey, look, I've did this cool bylaw for FIG.

It's all a mess, nobody cares about the current issues unless they are pushed by vocal folks. HTTP handling was a nice intention but nothing happened to it in months. Cache was opened for about and year, it nearly ended up in voting phase but suddenly it dropped dead. Logging passed in 3 weeks or so on the other hand. The new autoloader will pass in 3-4 weeks as well. Look at the authors of one PSR that's not voted and one that's voted and tell me it's not true.

There's so much stuff to do, like mails, DI containers, some other random but popular interfaces about things that are in every framework out there, but I guess the scope of the group got lost in personal issues. Instead of having interoperability we have autoloading mess, coding styles and a bit of logging. In almost 3 years of FIG (if I'm right). You are supposed to be those smart guys who make frameworks and libraries that a large part of the PHP community use, you are supposed to drive the innovation further and improve the image of PHP along the way but instead all you care about is something else it seems.

I'm waiting for these soon:

- PSR-5 - a PSR-2 refactoring but with tabs not spaces

- bylaw - we need a bylaw about bylaws in order to make bylaws bylawable.

Cheers and keep the bylaws coming.

[Pádraic Brady]

Hi Florin,

I've proposed the last two bylaws. One to govern membership when I
took over from Matthew and the second to help facilitate the adoption
of PSR-4.
We currently have one PSR put to a vote and a Cache PSR which on the
border of a vote. I've seen several others being discussed. I believe
the word you're in need of is "patience". Nobody here works full time
on PHP-FIG.

Paddy

--
Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team
Zend Framework PHP-FIG Representative

> --
> You received this message because you are subscribed to the Google Groups
> "PHP Framework Interoperability Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to php-fig+u...@googlegroups.com.
> To post to this group, send email to php...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/php-fig/-/UnLbD6VKuoQJ.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Phil Sturgeon]

There have been a few discussions about bylaws, and im about to post a new thread about another one. I'll expect a complaint from you when I do.

A lot of the conversations have come from me clearing out the Github issue tracker. We had about 50 issues in there, and now we have many less, but a lot of these had to be discussed in the group before closing them down or I'd just be hushing the masses and thats not helpful to anyone.

We've also had some clarity on "Can we change who represents a project without a vote" which is a pretty valid question, and now we're working out how to handle amendments or errata, another extremely valid question which thanks to Padraic's continued hard work since joining the FIG is finally getting towards a logical conclusion after a year of on-and-off again progress by various different people.

Now, what other non-bylaw things are being worked on?

• The Cache proposal is getting very close to a vote after Paul took a hiatus on working on it.
  
• A PHPDoc proposal is still being worked on by the phpDocumentor folks, which will finally give folks a single PHP standard instead of a de-facto standard which most doc systems mostly follow.
  
• A PHP autoloader which doesn't suffer from this naming oddity and has much more flexible folder structures.

If you aren't happy about these 3 items then thats unfortunate, but I see them as amazing steps for the FIG.

Your examples for PSR-5 are obviously silly and just trying to make a point, but PSR-5 will most likely be the Cache proposal. Nobody is interested in making a million PSR's which are only slightly different, but a PHP autoloader made in 2009 when PHP 5.2 was the most popular and PEAR was still a thing cannot be expected to last until the apes take over.

[Amy Stephen]

If everyone were honest, Florin has a point. There are a lot of people starting to make comments of this nature.

Now, I'll challenge the idea that the governance focus created problems. I actually think the opposite. It was an appropriate response to the problem of a lack of clear structure. It should help, but more structure will be needed.

I actually think quips like this one slow progress far more than most imagine and end up creating hard feelings for FIG. Florin has worked hard. He's earned our respect.

On Sunday, May 12, 2013 2:31:45 PM UTC-5, Phil Sturgeon wrote:

There have been a few discussions about bylaws, and im about to post a new thread about another one. I'll expect a complaint from you when I do.

Phil - I understand it's just a joke. The problem is, it's not a funny joke, it's a mocking joke.

A funny joke might be "How many PSR's does it take before FIG understands requiring the project name as the first node is all that is needed to addresses interoperability. The answer: X.

It's endearing to see a group mock themselves, once in awhile, it even builds trust, rebuilds enthusiasm, etc., and makes it all a little more fun.

Anyway. For what it is worth. =)

[Phil Sturgeon]

It wasn't meant to be a joke, I am frustrated. 

The irony of this topic is that discussing bylaws and refactoring PSRs is a waste of time, and more useful productive things should be done instead. I'd love to be doing that right now, but instead I am on a useless conversation about how much of a waste of time other useless conversations are. It's a circular problem.

Instead I'd prefer to spend some time blogging about the benefits of this new autoloader to help curb the obvious confusion, whining and pissantry that will be unleashed upon us once PSR-4 goes though as has always happened whenever the FIG have done anything - before eventually being accepted by the masses.

I welcome help in doing so, because several of the member projects are extremely excited about the chance to use PSR-4.

[Paul Jones]

On May 12, 2013, at 12:51 PM, Florin Patan wrote:

> There's so much stuff to do, like mails, DI containers, some other random but popular interfaces about things that are in every framework out there

You're so right! Please, by all means, pick one of those that is interesting to you. Do some research on the existing implementations in member projects, find the commonalities, write up a proposal, and and present it here.


-- pmj

[Hari K T]

To be frank, I will not blame Florin Patan for the frustration he addressed here, but could have been some more polite. May be if I am writing it may be more though on a frustrated time.

I think the problem occurs due to more members here, and we are not coming to consensus for the Cache , Http etc. And those who needs to implement knows it will take some time for FIG to standardize and they have a deadline or clear mile stone when their product to be released.

So they stay away from the discussions.

Hope all will be addressed.

Hari K T

http://harikt.com , https://github.com/auraphp

--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.

[Fabien Potencier]

Hi FIG,

I do not participate that much on this mailing-list as unfortunately, I
don't have much time these days. And I'm pretty sure I'm not alone in
this situation.

So, first, we need to keep in mind that people contributing one way or
another to this group are doing so in their free time, and mostly on top
of their involvement they already have in some PHP Open-Source projects.
I do respect and thank everyone for that... twice.

Now, I think that PSR-0 and PSR-3 addressed simple but vital
interoperability topics. I do think that Cache is in the same boat: we
should be able to find a consensus and settle on something that will
make everyone happy. Autoloading, Logging, and Cache are well-known
topics that are limited in scope; they are easy to standardize (and even
then, we had some tough discussions).

But when it comes to HTTP, DI containers, mails, ..., I'm more skeptical
that we will ever reach a consensus. Actually, I'm pretty sure that this
is a lost battle. These topics are large, complex, some of them quite
new in the PHP world, and more importantly, all of them can be solved in
many different and valid ways. Just have a look at Pimple and the
Symfony Service Container: two implementations of the same pattern but
with totally different solutions (and both were written by me). Also, I
think that such topics cannot be abstracted with interfaces only... at
least not in the PHP world.

Instead of finding topics to write yet another PSR, here my humble proposal:

What I would like to see happening is more collaboration between
projects belonging to this group. Interoperability is also about sharing
code. No need to write PSRs for that. A very good example is the lazy
proxy support recently added to both Zend Framework and Symfony: they
share the same third-party library to solve this problem. How can we do
more of that? Killing some libraries/components/... and replace them
with better/third-party ones whenever possible should probably be a
great goal for this group. I'm not saying that this is easier to do, but
that whould also help the PHP ecosystem as a whole.

Fabien

> --
> You received this message because you are subscribed to the Google
> Groups "PHP Framework Interoperability Group" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to php-fig+u...@googlegroups.com.
> To post to this group, send email to php...@googlegroups.com.

> To view this discussion on the web visit
> https://groups.google.com/d/msg/php-fig/-/UnLbD6VKuoQJ.

[Daniel Ribeiro]

Thank God.

Daniel Ribeiro Gomes Pereira

Twitter | Facebook | LinkedIn

iPhone: +55 (48) 9111-0931

2013/5/13 Fabien Potencier <fabien.p...@gmail.com>

an email to php-fig+unsubscribe@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msg/php-fig/-/UnLbD6VKuoQJ.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscribe@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.

[Phil Sturgeon]

That is being done, Laravel is using a bunch of Symfony components for example, but that is not discussed here because it is not relelvant to the whole group. :)

[Khayrattee Wasseem]

I totally agree with Fabien.
No need for more PSRs + more collaboration between projects IS way better! *5 Thumbs Up*

an email to php-fig+unsubscribe@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msg/php-fig/-/UnLbD6VKuoQJ.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscribe@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
Best regards,
Khayrattee Wasseem
(http://7php.com)

[Drak]

Thank heavens.

an email to php-fig+unsubscribe@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msg/php-fig/-/UnLbD6VKuoQJ.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscribe@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.

[Evert Pot]

> Instead of finding topics to write yet another PSR, here my humble proposal:
>
> What I would like to see happening is more collaboration between projects belonging to this group. Interoperability is also about sharing code. No need to write PSRs for that. A very good example is the lazy proxy support recently added to both Zend Framework and Symfony: they share the same third-party library to solve this problem. How can we do more of that? Killing some libraries/components/... and replace them with better/third-party ones whenever possible should probably be a great goal for this group. I'm not saying that this is easier to do, but that whould also help the PHP ecosystem as a whole.

I completely agree. I'd even go as far to make 'working together' a requirement for any PSR.

If I understand correctly, the IETF also requires a few working implementations for every rfc, before it may leave the 'draft' status.

I don't think some proof of concept code is enough. I feel that if we're one day going to get a Cache PSR out, it should already be implemented by a bunch of member projects to get some real-life experience with it.

Evert

[Donald Gilbert]

But that is a catch 22, because some projects don't want to change what they are doing unless there's an accepted PSR for it, and others don't want to accept PSR's until it's tested. Which route are you supposed to take?

[Paul Jones]

On May 13, 2013, at 1:53 PM, Evert Pot wrote:

> If I understand correctly, the IETF also requires a few working implementations for every rfc, before it may leave the 'draft' status.

Which is why I think it's important that we make recommendations based primarily on existing practices.

> I don't think some proof of concept code is enough. I feel that if we're one day going to get a Cache PSR out, it should already be implemented by a bunch of member projects to get some real-life experience with it.

Again, I agree, which is why I think the current Cache proposal is not that great -- it does not make reference to existing implementations.


-- pmj

[André R.]

On Monday, May 13, 2013 8:53:05 PM UTC+2, Evert Pot wrote: 

(..)

I don't think some proof of concept code is enough. I feel that if we're one day going to get a Cache PSR out, it should already be implemented by a bunch of member projects to get some real-life experience with it.

Big +1

And then the irony: Can anyone sketch up a bylaw for that? ;) 

[Evert Pot]

On May 13, 2013, at 7:55 PM, Donald Gilbert <dilber...@gmail.com> wrote:

> But that is a catch 22, because some projects don't want to change what they are doing unless there's an accepted PSR for it, and others don't want to accept PSR's until it's tested. Which route are you supposed to take?

That's just an assumption..

Evert

[Donald Gilbert]

No it's not. You're assuming that it's an assumption.

I'm a member of the Joomla Framework dev team, and we don't really want to change the way our HTTP classes work until there's a finalized and accepted PSR. We've taken what we believe will be the finalized version of the Cache PSR and implemented it, but it's not really what we wanted to do. We'd much prefer a finalized PSR before changing.

[Pádraic Brady]

Hi Fabien,

> I do not participate that much on this mailing-list as unfortunately, I
> don't have much time these days. And I'm pretty sure I'm not alone in this
> situation.
>
> So, first, we need to keep in mind that people contributing one way or
> another to this group are doing so in their free time, and mostly on top of
> their involvement they already have in some PHP Open-Source projects. I do
> respect and thank everyone for that... twice.

I appreciate this being mentioned since it can be forgotten ;).
PHP-FIG involvement subtracts from the time available to work on our
other open source and community projects/activities. It's a little
sacrifice for the greater good...so long as it remains "little".

> Now, I think that PSR-0 and PSR-3 addressed simple but vital
> interoperability topics. I do think that Cache is in the same boat: we
> should be able to find a consensus and settle on something that will make
> everyone happy. Autoloading, Logging, and Cache are well-known topics that
> are limited in scope; they are easy to standardize (and even then, we had
> some tough discussions).

As are BASIC operations using HTTP and email. Nothing obliges a PSR to
meet 100% coverage of every possible interaction or use case. The low
hanging fruit is as good a target as anything else and often the most
valuable to interoperability.

> Instead of finding topics to write yet another PSR, here my humble proposal:
>
> What I would like to see happening is more collaboration between projects
> belonging to this group. Interoperability is also about sharing code. No
> need to write PSRs for that. A very good example is the lazy proxy support
> recently added to both Zend Framework and Symfony: they share the same
> third-party library to solve this problem. How can we do more of that?
> Killing some libraries/components/... and replace them with
> better/third-party ones whenever possible should probably be a great goal
> for this group. I'm not saying that this is easier to do, but that whould
> also help the PHP ecosystem as a whole.

This is essential, of course, but how does one codify that behaviour
into a group? I can easily imagine us all sitting around a table a few
years ago discussing this very topic and arriving at the inevitable
conclusion that something beginning with P and another starting with S
needed to die. That would have require a concerted effort to improve
dependency management, distribution and packaging. Which is precisely
what happened anyway and which has driven some unprecedented code
sharing and collaborations. At the moment, our development environment
has evolved beyond the point where we need to debate the basics of
this. The ball is in each project's court to emphasise reuse and turn
their backs on NIH Syndrome (which is very much alive and kicking
though it's lost most of its power over us).

I'm pretty sure many are aware that Zend Framework's reputation here
was less than stellar ;). We evolved from something that reacted to a
rarity of reusable code (such as it was back in 2005) and that
ancestry and the culture it encouraged, in my opinion, really hurt us
at times. Even today, ZF has code which makes reuse a PITA but we try
to rectify that as the need arises. We can't eliminate history, just
remember not to repeat it!

So, I'm all for advocating greater reuse among member projects - just
not sure it can be made subject to mandatory standards and wavings of
a magic wand on a mailing list. If anything the best tool remains
pointing fingers and watching the target go a bit crazy in refactoring
towards better consumable units/packages. At least, I really hope they
go a bit crazy with enthusiasm. I admire how Paul made it front and
center in Aura. In a way, ask and you will receive. It costs nothing.

Paddy

[Amy Stephen]

Well, Florin, thank you for starting such an interesting discussion.  =)

Fabien - if the process for defining Interfaces stops, so will much of the getting rid of old libraries, and adopting the best of breed from what's out there. If nothing else, the process creates an exchange that starts a comparison process, creates a little competition, helps make all software better. If this process goes away, then, really you are suggesting projects sort of merge, which is fine, but it's going to actually hurt a lot of little projects.

One blog post you wrote was inspirational to me. The title was something like "Build your own framework" and in it - you shared the most amazing tutorial which helped define those basic application logic flow and features, and how to combine Symfony packages to build a framework.

There are lots of reasons someone should create yet another Cache package. Do we want new developers in the field? Do we want them to understand deeply the environment? For 30 years I have been in the industry, we have rebuilt that wheel many, many, many times - better and better, further reaching, more secure, faster, and so on.

Laravel has many Interfaces - if they'd be willing to share - that could jump start common code packages.

Also - maybe when folks come in with Interfaces, it doesn't have to be such a high standard to be considered. It doesn't have to be the best result to make it through. The cache interface is just fine - let it incrementally get better, just like code does.

But, if members are not enthusiastic about these goals - that certainly explains why the process isn't getting traction. No sense in forcing it if you don't feel it. But, I still think there is lots of value.

[Ryan McCue]

Donald Gilbert wrote:
> No it's not. You're assuming that it's an assumption.
>
> I'm a member of the Joomla Framework dev team, and we don't really want
> to change the way our HTTP classes work until there's a finalized and
> accepted PSR. We've taken what we believe will be the finalized version
> of the Cache PSR and implemented it, but it's not really what we wanted
> to do. We'd much prefer a finalized PSR before changing.

On the flip side, as the author of Requests, I'd like to implement a POC
of the PSR before it's finalised (once there's a consensus), for
multiple reasons:

1. To make sure I don't need any huge changes in my library if the PSR
is accepted
2. To check for any problems that may not have been considered in the
theoretical specification
3. To have a reference implementation that others can check against (and
assuming others also implement it, we can cross-check against each other)

I think it's important that we have at least one working implementation
of a PSR before we can accept it, otherwise things may cause huge
implementation problems and we don't notice. We don't need everyone to
implement it, as long as someone does.

--
Ryan McCue
<http://ryanmccue.info/>

[Larry Garfield]

I think this makes sense for interface-based PSRs. IETF's "2
implementations" rule is good, but I don't know if it's feasible in our
case. Having at least one implementation, though, lets us verify that a
spec is actually implementable in a non-crappy way. (An interface that
cannot be implemented in a non-crappy way is not that useful to
anyone.) Of course, if we want to do that right then we should have a
"Candidate Recommendation" phase like IETF and W3C do, with some minimum
time it must spend in that phase to let people try it out for-reals and
kick the tires.

I'd be supportive of that, but I suspect someone will cry "too much
process" on it...

--Larry Garfield

[Larry Garfield]

Fabien, let me clarify. Are you suggesting that FIG should not put out
common interface definitions but standard library implementations? In
that case, how would we keep FIG from turning into yet-another-PEAR or
yet-another-Zend or yet-another-Symfony? (All component libraries of
varying degrees of effective separation and reusability.) I don't think
we need a 4th component library vendor; we need more interchangeability
between "brands" of component library.

I don't actually think there's a good argument to be made for a single
DI interface spec, for precisely the reason you list: there are too many
very-valid ways to implement them, and the differences are not simply
cosmetic. That's not the case for, say, logging or cache interfaces.
Those are more easily commoditized.

--Larry Garfield

[Paul Dragoonis]

Hey,

Just caught up on this thread and I'd like the way the conversation is moving which brings me to my next point which I believe is super relevant to the group.

On the topic of "working together" or "sharing code" brought up multiple times by Fabien, Phil and so on. I believe the PPI Framework is a great example of the efforts and hard work we are putting in there to produce a truely "Interoperable Framework" by-design. I encourage people to take a look there and bring the good framework-agnostic parts/Interfaces back to FIG once we've solved the hard (very hard) problems. In my opinion PPI is a framework that encompasses the whole concept of FIG. https://github.com/ppi/framework/tree/2.1/PPI/

We're using Symfony for Routing, Templating, Request, Response & Autoloading (when composer isn't doing it)

We're using Zend Framework for ModuleManager (to bring modularity) and ServiceManager (to handle DI and services)

There's already talk here at FIG about generic Database interfaces. We already have generic Database Connection interfaces to provide commonalities for booting up each database library we support. We currently support Doctrine\DBAL, Doctrine\MongoDB, Monga, Laravel\DB, FuelPHP\DB and more are coming. You can see them here: https://github.com/ppi/framework/tree/2.1/PPI/DataSource/Connection

Over time we're going to be making our own generic interfaces for Routing libraries and Templating libraries so you can switch between them just like we have done with DataSource above, this might not be something FIG are interested at this time but we're aiming to provide interfaces for all major framework components over time.

We are looking for contributors to help solve problems similar to what we're doing here at FIG some of which are already listed here: http://www.ppi.io/contributors, so if anyone wants to help out and achieve framework interoperability we'd definitely appreciate the help there. is a good playground to brainstorm and try things before bringing them to FIG for official interfaces to be drafted up and standardised for all frameworks to potentially use.

Sorry if this is a bit long-winded but I had a lot to say at once to raise awareness of what we're doing at the pre-FIG approval stage and how it ties back into FIG which is more debating and procrastinating rather than coding which might suit certain types of people. I can shift this to a new thread if people feel it's not as relevant and I believe it is.

Thanks again to everyone at FIG who's worked hard on trying to make things better, you are superstars, you know who you are.

Cheers,

Paul

--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.

[Donald Gilbert]

And that's probably the middle ground we need. "Bleeding edge" developers to test / implement PSR's and others to implement after ratification. That will probably vary on a per-psr basis. I'm sure there will be some PSR's that come along (maybe some Joomla would propose) that we want to test and others would only implement after ratification.

[Fabien Potencier]

On 5/14/13 3:44 AM, Larry Garfield wrote:
> Fabien, let me clarify. Are you suggesting that FIG should not put out
> common interface definitions but standard library implementations? In
> that case, how would we keep FIG from turning into yet-another-PEAR or
> yet-another-Zend or yet-another-Symfony? (All component libraries of
> varying degrees of effective separation and reusability.) I don't think
> we need a 4th component library vendor; we need more interchangeability
> between "brands" of component library.

The creation of yet another standard library would be, in my opinion, a
terrible idea.

I'm advocating more cooperation between projects represented in this
group as it can probably help our goal : more **interoperability**
between PHP projects. If we can share more code, that's also a first
step toward **standardization**.

When I merged the lazy proxy feature in Symfony, some (not that many to
be fair) started to make stupid comments like "Symfony is now based on
Zend Framework" as if it was a great success for ZF and a failure on our
side. That makes me sad. I'm very proud that Symfony depends on the ZF
code generation library. Actually, I was very skeptical about supporting
proxies in the Symfony DIC in the fist place, but the fact that
third-party libraries already solved this problem made me re-consider
its inclusion in Symfony. I prefer to reuse code whenever possible and I
would not create an alternative implementation if something already
exists and is good enough. But do we need to standardize code generation
libraries by creating a PSR? Probably not. Let's take another example:
YAML. Do we need a standard interface for YAML parsers and dumpers? I
don't think so.

So, I think that we need to be very careful in the topics we are
choosing for the next PSRs. As it is very difficult to standardize
something, we'd better start with simple components. Cache is fine by me
(and so were Logging and Autoloading): simple components, well-known
"design patterns", not much room to innovate, implementations should be
quite similar in the end. DIC and HTTP are in a different league for the
reasons I exposed in my previous email.

To sum up, I really like the PSRs we have and I'm very enthusiastic
about the Cache initiative. I do like the work that was done recently on
the bylaws as it was much needed. I do thank all the people who
contributed to the bylaws (what a boring work) and the current PSRs. But
as for everything, let's use the right tool for the job; not all topics
are good candidates for a PSR. My proposal/dream is that for complex
topics, I would like to see more talks between projects directly to see
how we can **converge** some of our current implementations. Note that
I'm talking about talks between projects, I'm not saying that this
should be done on this mailing-list. That's probably a more pragmatic
approach that could potentially lead to PSR in the long run.

... and of course, that's just my 2 cents,
Fabien

[Lukas Kahwe Smith]

On May 14, 2013, at 10:48 , Fabien Potencier <fabien.p...@gmail.com> wrote:

> On 5/14/13 3:44 AM, Larry Garfield wrote:
>> Fabien, let me clarify. Are you suggesting that FIG should not put out
>> common interface definitions but standard library implementations? In
>> that case, how would we keep FIG from turning into yet-another-PEAR or
>> yet-another-Zend or yet-another-Symfony? (All component libraries of
>> varying degrees of effective separation and reusability.) I don't think
>> we need a 4th component library vendor; we need more interchangeability
>> between "brands" of component library.
>
> The creation of yet another standard library would be, in my opinion, a terrible idea.
>
> I'm advocating more cooperation between projects represented in this group as it can probably help our goal : more **interoperability** between PHP projects. If we can share more code, that's also a first step toward **standardization**.
>
> When I merged the lazy proxy feature in Symfony, some (not that many to be fair) started to make stupid comments like "Symfony is now based on Zend Framework" as if it was a great success for ZF and a failure on our side. That makes me sad. I'm very proud that Symfony depends on the ZF code generation library. Actually, I was very skeptical about supporting proxies in the Symfony DIC in the fist place, but the fact that third-party libraries already solved this problem made me re-consider its inclusion in Symfony. I prefer to reuse code whenever possible and I would not create an alternative implementation if something already exists and is good enough. But do we need to standardize code generation libraries by creating a PSR? Probably not. Let's take another example: YAML. Do we need a standard interface for YAML parsers and dumpers? I don't think so.
>
> So, I think that we need to be very careful in the topics we are choosing for the next PSRs. As it is very difficult to standardize something, we'd better start with simple components. Cache is fine by me (and so were Logging and Autoloading): simple components, well-known "design patterns", not much room to innovate, implementations should be quite similar in the end. DIC and HTTP are in a different league for the reasons I exposed in my previous email.
>
> To sum up, I really like the PSRs we have and I'm very enthusiastic about the Cache initiative. I do like the work that was done recently on the bylaws as it was much needed. I do thank all the people who contributed to the bylaws (what a boring work) and the current PSRs. But as for everything, let's use the right tool for the job; not all topics are good candidates for a PSR. My proposal/dream is that for complex topics, I would like to see more talks between projects directly to see how we can **converge** some of our current implementations. Note that I'm talking about talks between projects, I'm not saying that this should be done on this mailing-list. That's probably a more pragmatic approach that could potentially lead to PSR in the long run.

If I understand things properly Fabien is suggesting an additional approach slightly different than a PSR, which would be that through this group we also have a channel to discuss collaboration in terms of several projects adopting a specific component for a specific task. Going by what we have seen with Drupal and ezPublish adoption of Symfony components four of the big challenges there:

1) license (tricky topic .. some favor GPLv2 which in turn is incompatible with Apache v2 etc)
2) code packaging (largely solved by composer)
3) release process
4) security issue process

Maybe this is an area where we could try and ponder how we as a group can provide guidance and infrastructure to address these challenges and thereby reducing the legitimate concerns over adopting another projects components.

regards,
Lukas Kahwe Smith
sm...@pooteeweet.org

[Phil Sturgeon]

I dont think thats a topic for the PHP-FIG to worry about too much. Projects are reusing components without asking permission or help in this channel.

• Symfony are using ZF components
  
• Drupal, Laravel and PPI are using Symfony
  
• PyroCMS is using Symfony and Laravel

The logical convergence of code that we find useful is happening over time, and as and when things look like they could become a PSR we should propose it, but as Fabien says we don't need to go mad ratifying everything we can get our hands on. DiC in my opinion shouldnt be, as the same thing can be done a bunch of different ways. 

Compare that to something like HTTP Messges and you have a spec in place for how that should work, so all we have to do is pick a bunch of method names to represent that and its job done.

YAML also obviously would not need to become a PSR standard, projects just elect to use the best one they can get their hands on, and I'm loving Symfony's.

The job of this group is to produce PSRs. Yes, sometimes it takes a while, and yes sometimes we have to spend time talking about bylaws and taking surveys to get people on the same page, but it's all for the greater good even if its boring or not immediately beneficial to everyone.

[Fabien Potencier]

About point 4), and you are interested in knowing more about it, I've
just added a new paragraph about our security issue process and how we
work with projects using Symfony in our documentation:
https://github.com/symfony/symfony-docs/pull/2639/files

[Larry Garfield]

On 5/14/13 7:38 AM, Phil Sturgeon wrote:
> I dont think thats a topic for the PHP-FIG to worry about too much.
> Projects are reusing components without asking permission or help in
> this channel.
>

> * Symfony are using ZF components
> * Drupal, Laravel and PPI are using Symfony
> * PyroCMS is using Symfony and Laravel

>
> The logical convergence of code that we find useful is happening over
> time, and as and when things look like they could become a PSR we should
> propose it, but as Fabien says we don't need to go mad ratifying
> everything we can get our hands on. DiC in my opinion shouldnt be, as
> the same thing can be done a bunch of different ways.
>
> Compare that to something like HTTP Messges and you have a spec in place
> for how that should work, so all we have to do is pick a bunch of method
> names to represent that and its job done.
>
> YAML also obviously would not need to become a PSR standard, projects
> just elect to use the best one they can get their hands on, and I'm
> loving Symfony's.
>
> The job of this group is to produce PSRs. Yes, sometimes it takes a
> while, and yes sometimes we have to spend time talking about bylaws and
> taking surveys to get people on the same page, but it's all for the

> greater good even if its boring or not /immediately/ beneficial to everyone.

From the web site:

"The idea behind the group is for project representatives to talk about
the commonalities between our projects and find ways we can work together."

So it's quite a stretch to go from there to "our job is to produce
PSRs". That also lends itself toward measuring our success as an
organization primarily by the number of PSRs we put out, which would be
both a fairly negative grade (we're averaging about one a year over the
group's lifetime) as well as counter-productive.

What Fabien is suggesting is something different, but I'm not entirely
sure how it would work. Fabien, for example, how would you foresee FIG
playing a role in:

- Standardizing the process and schedule for security releases? (Your
previous link shows how Symfony is planning to coordinate with its
downstream clients, but that's just one small part of the ecosystem.)

- Folding the Symfony and Zend YAML parsers (neither of which is a
perfect or entirely complete implementation AFAIK) into one universal
rock solid and 100% complete YAML parser.

- Standardizing HTTP request/response handling in some useful way other
than common interfaces that can be shared by Guzzle, Zend, Symfony,
Drupal, Solarium, etc? (I can absolutely see the use of common
interfaces there, as witnessed by recent discussions between Drupal and
Zend about using Zend_Feed with Guzzle in Drupal 8.)

- Sorting out "best licensing practices" (which is a landmine and a half
even within a single project, to say nothing of cross-project)

(Note: I'm not against any of the above, mind you; more I'm interested
in how you'd see it happening.)

Also, if any of those produced a document at the end (PSR or otherwise),
those would all be "soft specs". The poll I ran a few weeks ago showed
a very clear preference, both among voting members and non-voting
participants, for "hard specs", i.e., interfaces.

--Larry Garfield

[Evert Pot]

On May 13, 2013, at 8:19 PM, Donald Gilbert <dilber...@gmail.com> wrote:

> No it's not. You're assuming that it's an assumption.
>
> I'm a member of the Joomla Framework dev team, and we don't really want to change the way our HTTP classes work until there's a finalized and accepted PSR. We've taken what we believe will be the finalized version of the Cache PSR and implemented it, but it's not really what we wanted to do. We'd much prefer a finalized PSR before changing.

So you're saying your development process does not allow you to to branch out and create a proof of concept. I completely understand not wanting to release things that are likely to change, especially if they are core, but a proof of concept does not have to be a (and probably should not be) part of a stable release..

Evert

[Donald Gilbert]

I'm saying for some things, it's not worth our time and effort to build a POC when what we have is functioning very well. We'll gladly update to stay compatible once finalized, but volunteers are few and working on things for the sake of building a POC won't be something that EVERY member project is going to want to do with EVERY proposed psr. Hence my follow up comment to someone else:

"I'm sure there will be some PSR's that come along (maybe some Joomla would propose) that we want to test and others would only implement after ratification."

That's all, nothing more, nothing less.

[Evert Pot]

On May 14, 2013, at 5:33 PM, Donald Gilbert <dilber...@gmail.com> wrote:

> I'm saying for some things, it's not worth our time and effort to build a POC when what we have is functioning very well. We'll gladly update to stay compatible once finalized, but volunteers are few and working on things for the sake of building a POC won't be something that EVERY member project is going to want to do with EVERY proposed psr. Hence my follow up comment to someone else:
>
> "I'm sure there will be some PSR's that come along (maybe some Joomla would propose) that we want to test and others would only implement after ratification."
>
> That's all, nothing more, nothing less.

Well that's completely fair, but I also never proposed for everyone to make a PoC for every draft we have.

My suggestion was to have a few in place so we can test it in the wild, gather feedback. Especially if there's a PSR you're specifically putting forward, it would certainly be a sign of good faith to also have some real-world experience with the ramifications.

To hear you guys integrated the draft for caching is interesting to hear btw.. Which draft did you use?

Evert

[justin]

On Tue, May 14, 2013 at 9:38 AM, Evert Pot <ever...@gmail.com> wrote:

My suggestion was to have a few in place so we can test it in the wild, gather feedback. Especially if there's a PSR you're specifically putting forward, it would certainly be a sign of good faith to also have some real-world experience with the ramifications.

Agreed. This is one thing missing from our seeming fascination with the IETF style "never change anything" recommendations... In order to be approved as an RFC, not only is there a pre-defined waiting period, but there's also a "real-world implementations" policy. Without it, we will inevitably end up with confusion and edge cases that could have been avoided. If we're not willing to change things that are wrong once they've been approved, we must be willing to put the work into making sure everything is right before they are ratified.

-- justin

[Larry Garfield]

I should also note that trial implementations don't need to be "part of"
a given framework/platform/application, and in fact would be better if
they're not. As an example, I threw together a PHP implementation of
IETF's api-problem in an afternoon:

https://github.com/Crell/ApiProblem

It's not tied to Drupal or any other framework, by design. It just is.
But, it's an implementation. (Quality debatable, but it's there.)
Drupal can trivially pull it in if it wants to:

http://drupal.org/node/1916302

I'd actually think that a "trial" cache implementation would be better
done stand-alone like that, NOT within Joomla, or Drupal, or Symfony,
etc. Done by Joomla, or Drupal, or Symfony people, sure, but not in
those repositories.

That has the nice side effect of forcing more decoupling and fewer
dependencies, which can only help.

--Larry Garfield

[Paul Dragoonis]

I'm going to begin adding some Traits and perhaps an AbstractCache class too as part of Psr\Cache, just like we did with Psr\Log.

 

That has the nice side effect of forcing more decoupling and fewer dependencies, which can only help.

--Larry Garfield

--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscribe@googlegroups.com.

[Pádraic Brady]

>- Standardizing the process and schedule for security releases? (Your previous link shows how Symfony
>is planning to coordinate with its downstream clients, but that's just one small part of the ecosystem.)

Let's take an example here, at a bit of a stretch. I know Fabien has
rolled out https://security.sensiolabs.org/ which tracks
vulnerabilities for ~4 projects (Symfony, ZF, Doctrine and 1/2 other
Symfony related projects). The idea being to use this service to
assess whether your current depedendency versions are clean of normal
vulnerabilities. If we take interoperability into account, we could
consider:

1. Do member projects follow a "good" vulnerability reporting/resolution policy?
2. Do member projects disclose their vulnerability details in a
consumable format (i.e. so one could pull rather than push data into a
service)?
3. Could we encourage member projects to move towards 1 and 2 and make
the Sensio Labs service more inclusive?
4. Can we build in third party disclosures (e.g. Project X refuses to
fix or publish details of a vulnerability)?

If we could put that together into a soft standard and have more
people follow it, and an appropriate service allowing for wider
submissions, cross-member peer review, etc.) it would help. No idea
how realistic it is - my honest opinion is that disclosing
vulnerabilities is not exactly high on everyone's agenda ;).
Nevertheless... Having something to quickly sanity check your locked
dependency versions was and is a great idea.

Paddy



--
Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team
Zend Framework PHP-FIG Representative

[Donald Gilbert]

My original remarks could have been better worded to include my thought process which could relieve some mis-understandings.

I can't remember whose it was in particular (the effort was done by Andrew Eddie), but I know we implemented back when they were more different than they were today. The code we implemented is here: https://github.com/joomla/joomla-framework/tree/staging/vendor/psr/cache/Psr/Cache

[Paul Dragoonis]

On Tue, May 14, 2013 at 6:33 PM, Donald Gilbert <dilber...@gmail.com> wrote:

My original remarks could have been better worded to include my thought process which could relieve some mis-understandings.

I can't remember whose it was in particular (the effort was done by Andrew Eddie), but I know we implemented back when they were more different than they were today. The code we implemented is here: https://github.com/joomla/joomla-framework/tree/staging/vendor/psr/cache/Psr/Cache

I was speaking with Andrew at the time, we wanted this in Joomla a bit in advance to test the waters, the same is being done at PPI. It shouldn't be pushed to production yet since Psr\Cache is still subject to some change while things are being finalised.

 

On Tuesday, May 14, 2013 11:38:13 AM UTC-5, Evert Pot wrote:

Well that's completely fair, but I also never proposed for everyone to make a PoC for every draft we have.

My suggestion was to have a few in place so we can test it in the wild, gather feedback. Especially if there's a PSR you're specifically putting forward, it would certainly be a sign of good faith to also have some real-world experience with the ramifications.

To hear you guys integrated the draft for caching is interesting to hear btw.. Which draft did you use?

Evert

--

You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/a52526ab-b966-4a73-9978-91d37de4e328%40googlegroups.com?hl=en.

[Phil Sturgeon]

On Tuesday, 14 May 2013 12:03:14 UTC-4, Larry Garfield wrote:

 From the web site:

"The idea behind the group is for project representatives to talk about
the commonalities between our projects and find ways we can work together."

So it's quite a stretch to go from there to "our job is to produce
PSRs".  

Right, we find commonalities between our projects and work together. PSRs codify these agreements, but we don't need the whole group to sit down and vote on wether or not Laravel uses a Symfony component (obviously). We can work together without it being a whole big FIG thing.

 

That also lends itself toward measuring our success as an
organization primarily by the number of PSRs we put out, which would be
both a fairly negative grade (we're averaging about one a year over the
group's lifetime) as well as counter-productive.

It looks set to double in the next 6 months, so that would be a nice chart to plot.

 

- Standardizing the process and schedule for security releases?  (Your
previous link shows how Symfony is planning to coordinate with its
downstream clients, but that's just one small part of the ecosystem.)

Let's all be Symfony developers! (?)

 

- Folding the Symfony and Zend YAML parsers (neither of which is a
perfect or entirely complete implementation AFAIK) into one universal
rock solid and 100% complete YAML parser.

Under what namespace? The FIG should shout at Zend and Symfony and get one of them to deprecate their package?

 

- Standardizing HTTP request/response handling in some useful way other
than common interfaces that can be shared by Guzzle, Zend, Symfony,
Drupal, Solarium, etc?  (I can absolutely see the use of common
interfaces there, as witnessed by recent discussions between Drupal and
Zend about using Zend_Feed with Guzzle in Drupal 8.)

This is what the folks were doing for the HTTP Message PSR. Why would this be better as not a shared interface? 

 

- Sorting out "best licensing practices" (which is a landmine and a half
even within a single project, to say nothing of cross-project)

I'm not sure what this has to do with this conversation?

[Moisa Teodor]

Hi Fabien, all,

While I agree with everything you said,

Let's take another example: YAML. Do we need a standard interface for YAML parsers and dumpers? I don't think so.

YAML has it's own specification and there's no need for a PSR on top of that. Maybe a 'Config' PSR that defines a basic interface for configuration handling libraries would be useful thought. 

--
Doru Moisa
web: http;//moisadoru.wordpress.com
tel: +40 720 861 922
Bucharest, Romania

[Evert Pot]

> - Folding the Symfony and Zend YAML parsers (neither of which is a
> perfect or entirely complete implementation AFAIK) into one universal
> rock solid and 100% complete YAML parser.
>
> Under what namespace? The FIG should shout at Zend and Symfony and get one of them to deprecate their package?

If Zend and Symfony would like to create a universal YAML parser between the two of them, and somehow this group can be a catalyst to organize such an operation, I think it would be great.

Who cares if there's no official PSR document associated with it. I feel that (nod to Fabian's point) that if this group's prime directive is to improve interoperability between projects, we should provide a platform for other projects to arrange this.

If hypothetically Zend and Symfony are interested in doing this, this list would make for a great place to ask which member projects are also interested in joining this effort and setup a small working group.

Evert

[Larry Garfield]

On 5/14/13 1:01 PM, Phil Sturgeon wrote:

> - Standardizing the process and schedule for security releases? (Your
> previous link shows how Symfony is planning to coordinate with its
> downstream clients, but that's just one small part of the ecosystem.)
>
> Let's all be Symfony developers! (?)

I'm going to assume this is just sarcasm. :-)

> - Folding the Symfony and Zend YAML parsers (neither of which is a
> perfect or entirely complete implementation AFAIK) into one universal
> rock solid and 100% complete YAML parser.
>
>
> Under what namespace? The FIG should shout at Zend and Symfony and get
> one of them to deprecate their package?
>
> - Standardizing HTTP request/response handling in some useful way other
> than common interfaces that can be shared by Guzzle, Zend, Symfony,
> Drupal, Solarium, etc? (I can absolutely see the use of common
> interfaces there, as witnessed by recent discussions between Drupal and
> Zend about using Zend_Feed with Guzzle in Drupal 8.)
>
>
> This is what the folks were doing for the HTTP Message PSR. Why would
> this be better as not a shared interface?
>
> - Sorting out "best licensing practices" (which is a landmine and a
> half
> even within a single project, to say nothing of cross-project)
>
>
> I'm not sure what this has to do with this conversation?

I wasn't putting forward the above as an agenda for FIG. I was
specifically asking Fabien how he would envision FIG helping toward
those example goals, which were drawn from his post and Lukas' follow-up.

So basically... "I wasn't asking you." :-)

--Larry Garfield

[Phil Sturgeon]

It was jovial sarcasm sure. I get that you weren't asking me but most of this is a silly conversation to have. We have no place meddling with Symfony and nobody should expect us to.

In response to Evert, it would be nice if Symfony and Zend merge some packages and make universal ones, but that sounds very much like making a universal standard library. I don't care if I'm being asked, if I spot a conversation getting close to that I'm going to kick up a fuss. We're not here to make PEAR3.

[Evert Pot]

On May 14, 2013, at 8:14 PM, Phil Sturgeon <em...@philsturgeon.co.uk> wrote:

> It was jovial sarcasm sure. I get that you weren't asking me but most of this is a silly conversation to have. We have no place meddling with Symfony and nobody should expect us to.
>
> In response to Evert, it would be nice if Symfony and Zend merge some packages and make universal ones, but that sounds very much like making a universal standard library. I don't care if I'm being asked, if I spot a conversation getting close to that I'm going to kick up a fuss. We're not here to make PEAR3.

I don't think anybody is actually interested in making a universal standard library... I find it hard to believe that you yourself would believe this to be a realistic outcome.

My point stands though, if we can facilitate people working together better.. even if it's casual and informal, I'd welcome it with open arms.

Even if it's just the occasional announcement, like "Hey guys, project X and project Y are now working together on component Z", I'd think it to be a positive thing.

Would be a nice break too from all hostile bureaucratics.

Evert

[Lukas Kahwe Smith]

On May 14, 2013, at 21:14 , Phil Sturgeon <em...@philsturgeon.co.uk> wrote:

> It was jovial sarcasm sure. I get that you weren't asking me but most of this is a silly conversation to have. We have no place meddling with Symfony and nobody should expect us to.
>
> In response to Evert, it would be nice if Symfony and Zend merge some packages and make universal ones, but that sounds very much like making a universal standard library. I don't care if I'm being asked, if I spot a conversation getting close to that I'm going to kick up a fuss. We're not here to make PEAR3.

What I am seeing being proposed here isnt a super repository but more coordination along the lines of (and this is just a random example): Zend deprecates their Yaml parser in favor of Symfony's to direct resources towards its Http client which becomes the defacto blessed Http client for Symfony and Drupal users. No code is moved to a new super organization.

[Amy Stephen]

On Tuesday, May 14, 2013 12:19:44 PM UTC-5, Pádraic Brady wrote:

 If we take interoperability into account, we could
consider:

1. Do member projects follow a "good" vulnerability reporting/resolution policy?
2. Do member projects disclose their vulnerability details in a
consumable format (i.e. so one could pull rather than push data into a
service)?
3. Could we encourage member projects to move towards 1 and 2 and make
the Sensio Labs service more inclusive?
4. Can we build in third party disclosures (e.g. Project X refuses to
fix or publish details of a vulnerability)?

Paddy - +1 I think that would be very helpful. The same could be said about quality practices with unit testing, standards sniffing, copy and paste detection, and so on. Helps to form a body of material newer, smaller PHP projects can use to begin with good practices. 

[Larry Garfield]

On 5/14/13 3:38 PM, Amy Stephen wrote:

That reminds me of something from many moons ago.

After the GoPHP5 project was successful in assassinating PHP 4, I
briefly spoke with Jonah Braun (I think that was his name) from Joomla
about some central way to track what projects required what PHP versions
and PECL libraries AND what web hosts offered what version of PHP and
what PECL libraries. Basically an ongoing way to put pressure on hosts
to move to new versions of PHP, and for projects to get a better sense
of when it's "safe" to move to new versions without resorting to too
much guessing. I thought it was a good idea, but neither of us really
had the time to do anything with it.

Some of that may now be tracked by Composer. However, not all projects
are distributed through Composer (even Drupal isn't yet), and not all
Composer projects specify a minimum PHP version or required PECL
libraries. (Jordi, is there any way to get stats on that?) And then
we'd need to figure out how to do the counter-part, figuring out what
hosts offer.

Is that the sort of thing anyone here would be interested in? I'm not
entirely sure how we'd do it even if we decided to, but it seems more in
line with the "coordinate best practices" thinking of the more vocal
participants around here.

--Larry Garfield

[FGM at GMail]

npmjs has direct CouchDB access to allow cloning of the NPM (Node.JS) package
database. Maybe Packagist offers this somewhere too ?

2013/5/15 Larry Garfield <la...@garfieldtech.com>:

> On 5/14/13 3:38 PM, Amy Stephen wrote:
>>

> --
> You received this message because you are subscribed to the Google Groups
> "PHP Framework Interoperability Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to php-fig+u...@googlegroups.com.
> To post to this group, send email to php...@googlegroups.com.

[Phil Sturgeon]

I don't think anybody is actually interested in making a universal standard library... I find it hard to believe that you yourself would believe this to be a realistic outcome.

I don't believe thats what was being suggested by you, or by any of the other voting members but I got the feeling a few other folks thought that is what was being discussed. I'm generally against the whole "PSR BAD, MERGE ALL THE CODE GOOD" approach that seemed to be cropping up in this conversation, as I'm sure you'll agree there is a place for both.

 

My point stands though, if we can facilitate people working together better.. even if it's casual and informal, I'd welcome it with open arms. 

Even if it's just the occasional announcement, like "Hey guys, project X and project Y are now working together on component Z", I'd think it to be a positive thing.

Absof**kinglutely, as long as we're still working on building out quality PSRs in between all of that - which again im sure most of you are fine with.

Lukas: 

What I am seeing being proposed here isnt a super repository but more coordination along the lines of (and this is just a random example): Zend deprecates their Yaml parser in favor of Symfony's to direct resources towards its Http client which becomes the defacto blessed Http client for Symfony and Drupal users. No code is moved to a new super organization. 

I'd be super-happy to see that happen. A few years ago I'd have said no chance, and I'm still dubious, but if folks on both projects can come together on an agreement to deprecate and/or merge various components together then that is another great step for the PHP community. If they can do it, then sure, here seems like a reasonable place.

[Drak]

I suppose Fabien is talking about something like ISO standards for procedures too though. How projects deal with vulnerabilities for example. Giving some recommendations on how to deal with stuff like that might really help the community. Smaller projects may not really have enough experience with the best procedures. If projects can agree on a framework for this kind of intercommunication (via a PSR for example) it could really really change help interoperability and collaboration. 

I'm just up from a nap, so I hope you get the gist of what I mean - it might not be eloquently, but hopefully the meaning is there.

Regards,

Drak

--

You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/ca395bf0-9e14-4c48-bbf4-9d36d8e7f6f2%40googlegroups.com?hl=en.

[Hari K T]

Hi

I'd be super-happy to see that happen. A few years ago I'd have said no chance, and I'm still dubious, but if folks on both projects can come together on an agreement to deprecate and/or merge various components together then that is another great step for the PHP community. If they can do it, then sure, here seems like a reasonable place.

what I thought about FIG is people can switch between the vendors without any issues.

For eg :

if I am building a framework or a cms system ,

I can plug Aura.Router or can replace it with Symfony2 router or any other routing system without any issues.

So the methods and all remain the same. I don't think re-inventing something is a Bad idea either or NIH is bad, for we all are doing the same things though we try to say we are against it .

[Lukas Kahwe Smith]

On May 15, 2013, at 18:02 , Hari K T <ktha...@gmail.com> wrote:

> Hi
>
> I'd be super-happy to see that happen. A few years ago I'd have said no chance, and I'm still dubious, but if folks on both projects can come together on an agreement to deprecate and/or merge various components together then that is another great step for the PHP community. If they can do it, then sure, here seems like a reasonable place.
>
> what I thought about FIG is people can switch between the vendors without any issues.
>
> For eg :
>
> if I am building a framework or a cms system ,
>
> I can plug Aura.Router or can replace it with Symfony2 router or any other routing system without any issues.

That is one strategy which we will continue to follow with interface level PSRs.
What is being discussed is to run another strategy in parallel that tries to push towards convergence.
Convergence makes sense if one implementation approach is deemed superior and so other implementations might just be eaten dev resources and not really providing additional benefits.

> So the methods and all remain the same. I don't think re-inventing something is a Bad idea either or NIH is bad, for we all are doing the same things though we try to say we are against it .

There is a difference with providing the same functionality with a different approach and doing exactly the same with essentially zero practical differences.

Now there is of course also a non technical dimension to collaboration (licenses, coding style, trust that reasonable patches will be accepted, security and release processes). This is the other dimension that is being discussed in this thread. Reducing the need for NIH for non technical reasons.

[Pádraic Brady]

The thread is getting a wee bit noisy so I took this particular idea
to the blog:
http://blog.astrumfutura.com/2013/05/publishing-security-disclosures-in-consumable-formats-for-simpler-aggregation-and-security-checking

It seems practical enough that it could be discussed in a separate
thread one day soon...

Paddy

--