An open letter to PHP-FIG

[Anthony Ferrara]

All,

http://blog.ircmaxell.com/2014/10/an-open-letter-to-php-fig.html

Anthony

[Jordi Boggiano]

On 15/10/2014 12:07, Anthony Ferrara wrote:
> http://blog.ircmaxell.com/2014/10/an-open-letter-to-php-fig.html

I fully agree, thanks for saying it!

Moreover, one of the other issues of solving 99% problems is at the
organizational level. Even if we don't consider the code, PSR-6 and
PSR-7 are very large and that makes it hard to review. It creates long
discussions about details where nobody can reach an agreement, it lasts
forever so new people keep coming to the table.

And I may not be the only one that just doesn't have enough time to dive
in, read the whole spec and give constructive feedback. That'll likely
lead to specs being rejected because people go "WTF?" when finally
looking at it before voting.

I would therefore urge the 6/7 folks to try to refocus on more minimal
scopes and get that passed ASAP, then work on extending those can be
again focused on a small extension point and nobody will be able to
waste time discussing the basic interfaces over and over.

Cheers

--
Jordi Boggiano
@seldaek - http://nelm.io/jordi

[Paul Dragoonis]

On Wed, Oct 15, 2014 at 12:07 PM, Anthony Ferrara <ircm...@gmail.com> wrote:

All,

http://blog.ircmaxell.com/2014/10/an-open-letter-to-php-fig.html

Thanks for your comments on PSR-Cache, I agree with parts of what you said.

My original proposal was on "weak items" which matches your suggestion.

Robert's proposal was on "strong items", which went to a vote and the group went for strong items.

I believe weak and strong solve some problems better than each other.

Thanks for your time.

 

Anthony

--
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/459ead4a-522c-4bd2-b4dc-c1c3f27461f7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Anthony Ferrara]

Paul,

The only part I'd like to point out is that this isn't really limited
to the Cache proposal. If it was just that one feature, I would have
replied directly in that thread saying that.

The point I was trying to make is that it seems like a general trend,
looking at recent proposals (including HTTP messaging, etc). And
that's why it was an open letter. Because it seems to be an overall
"difference" in the fundamental objective and direction of the group.

I definitely want this to be a constructive discussion. I just want to
be sure it's focused on the correct scope...

Thanks,

Anthony

> https://groups.google.com/d/msgid/php-fig/CAKxcST_xmzWFBTO1HKy_QnHDcZbNHUgruWx67ymBWnujV1pw-w%40mail.gmail.com.

[Philip Sturgeon]

On Wednesday, October 15, 2014 6:07:45 AM UTC-5, Anthony Ferrara wrote:

All,

http://blog.ircmaxell.com/2014/10/an-open-letter-to-php-fig.html

Anthony

Thanks for adding the bit about Tags. 

I know exactly what you mean about sticking to the 50% and not trying to solve 99%, and thats how I have always wanted PSRs to go. It's very easy to scope creep them into an obnoxious mess once the CompSci bros get their hands on it and start using terms I've never heard of. 

It's hard, because I know why adding the "Stong Item" approach helps. I've said this to you before, but I feel that just adding the item class does not mean that we are trying to solve 99% of the problems. By defining a item class which only covers some of the functionality (TTL) we are allowing others "in the wild" to extend it and add their own functionality, which we can use to make an expanded Cache interface in the future.

All of this said, I am not so much a proponent of the item class, but I can defend its choice by the group as not completely over the top.

Complexities in other areas however, like multi-get, multi-set and all sorts of other deferred save stuff... erf. It's changed so many times I don't have a clue and I've properly given up trying to work out where it is this week. 

Jordi: I know what you mean about it being impossible to keep up with things. This is why I suggested the Review period, so anyone not completely involved in its ongoing creation has two weeks (at least) to Review, then another two weeks to get a vote in before the vote closes. Everyone in this group should be able to find an hour or two to look through a review proposal in a whole month. 

If thats not cool, maybe we extend review period. 

Big PSRs = Bigger Review periods.

But we could totally make smaller PSRs too.

In regards to HTTP Message, I'm not particularly happy with the IncomingRequest stuff.

I want to purely describe the HTTP Message, not have getQueryParams, URI logic, cookie crap and god knows what else. That could be a job for third party implementations for now, and an interface on top later. I've expressed that, but I've been a minority it seems.

I want more, smaller, PSRs, that come out, deprecate old ones, and let people use bigger and better things.

That can't be so unreasonable. The whole HTTP RFC was completely replaced WHILE MAKING the HTTP Message spec, and was split into smaller, more manageable RFCs. 

We can do the same. A PSR lasting for a year then being improved is just fine. 

Which, is why also, deprecate PSR-0. See the pattern here? :)

[Dracony]

To me the IncomingRequestInterface also seems a bit over the top. 

Though I totally understand the rationale behind it, but it looks like it would fit more as an RFC for the actual language rather an interpolability interface.

Most frameworks have their own ways of representing the incoming HTTP request, and it's usually somewhere near the frameworks kernel, and not much stuff interacts with that interpretation directly.

If this was a core PHP feature, like instead of having all those superglobals I could just IncomingRequest::getInstance ( ) or whatever, that would be so much more awesome and useful.

On the other hand perhaps including it in a PSR will be a nice step towards actually including it in PHP.

But it might be better off as a separate PSR, since it has less to do with the HTTP protocol and more with PHP superglobals.

[Lukas Kahwe Smith]

Just for the record:
I think the open letter was not about discussing specifics of any PSR.
The PSR referenced where just examples.

As such if you do want to discuss the examples there in, probably best to open new threads.

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

[Taylor Otwell]

I can totally relate to this. It's so hard to review these proposals until the very end when there is an actual vote. There needs to be a MUCH better process for distributing incremental updates for people to easily digest and understand before things come to that point.

[Matthew Weier O'Phinney]

On Wed, Oct 15, 2014 at 11:19 AM, Dracony <draco...@gmail.com> wrote:
> To me the IncomingRequestInterface also seems a bit over the top.
> Though I totally understand the rationale behind it, but it looks like it
> would fit more as an RFC for the actual language rather an interpolability
> interface.
> Most frameworks have their own ways of representing the incoming HTTP
> request, and it's usually somewhere near the frameworks kernel, and not much
> stuff interacts with that interpretation directly.

Um, actually, not true, and that's why the IncomingRequestInterface
exists. Most modern frameworks pass around the request object (to
routers, to controllers, to events, etc.). And friction occurs if you
try to mix-and-match code from one framework to another when such
objects are involved.

As a case study: in zf-oauth2, we consume oauth2-server-php. In order
to do so, we need to invoke a controller from the latter -- which
means passing a request and response pair. Of course, we already have
our own -- but now we need to marshal instances for oauth2-server-php,
and ensure that all the incoming data is in the correct format and
properly injected. In particular, the body content is problematic --
because php://input is read-once prior to PHP 5.6. And then we need to
grab stuff out of the returned response and determine (a) what to do
with it, and (b) how to stuff it into our own.

Having a common interface for getting at these details would mean we
could pass our request and response pair directly, without any
translation layer.

Also, consider situations such as Apigility, where you may want to
expose code from your application written in Symfony, or Laravel, or
PPI, etc -- having common request/response interfaces would simplify
this greatly. (Right now, you have to write bridges for each different
framework you want to delegate to.)

All of this is in the http-message-meta.md document. Evidently folks
are not reading the meta documents though, because the same arguments
keep occurring.

> If this was a core PHP feature, like instead of having all those
> superglobals I could just IncomingRequest::getInstance ( ) or whatever, that
> would be so much more awesome and useful.
> On the other hand perhaps including it in a PSR will be a nice step towards
> actually including it in PHP.

That's really the point. I want to see HTTP messages as primary,
supported citizens of PHP -- and this includes abstraction around the
incoming request data, too -- as it would deprecate monolithic
frameworks and promote the idea of smaller, targetted code that
interacts with them in order to perform common workflows. (E.g.,
content negotiation, cache control header manipulation, etc.)

If this proposal is accepted, and becomes widely adopted, perhaps we
can then push it into the PHP core. In the meantime, we'd have a
wonderful forward-compatible emulation in userland.

> But it might be better off as a separate PSR, since it has less to do with
> the HTTP protocol and more with PHP superglobals.

Several have suggested this. I've chosen to keep it as part of the
HTTP Message PSR because the actual interface is relatively
lightweight (particularly with the changes I've incorporated today),
and because the HTTP messages by themselves are primarily useful for
clients -- while I want to see greater interop amongst those writing
server-side code in particular.


--
Matthew Weier O'Phinney
mweiero...@gmail.com
https://mwop.net/

[Korvin Szanto]

+1

> --
> 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/6a665aa9-1ec3-4122-9ebc-1c6608bf8fc1%40googlegroups.com.

[Philip Sturgeon]

On Wednesday, October 15, 2014 11:36:45 AM UTC-5, Taylor Otwell wrote:

I can totally relate to this. It's so hard to review these proposals until the very end when there is an actual vote. There needs to be a MUCH better process for distributing incremental updates for people to easily digest and understand before things come to that point.

Did you see my reply on this? How do you feel about longer review periods. Is that the problem, or something else? 

 

[Robert Hafner]

The problem is, in my opinion, that there are two many cooks in the kitchen and many of them care more about driving traffic to their blogs than they do about this group (hence why I’m not surprised this “open letter” was not even sent to this group directly until someone asked). 

Here’s the cycle I see-

1. People find a need- such as Logging, Caching, or HTTP Messages- and it gets some sponsors.

2. Proposal gets written, and a dozen or so people spend their time tearing it apart and making it better.

3. Random person enters, tears apart proposal based off of misunderstandings.

4. People work with Random person, show them why things work the way they do, and get them on board.

5. Work continues for a bit, and we think we’re getting close.

6. Return to 3.

7. Return to 3.

8. Return to 3.

9. Return to 3.

10. Return to 3.

11. Give up.

Frankly, we have a bunch of people who are not at all engaged who randomly pop in and decide it’s the most important thing ever, then we spend our time trying to educate them (one at a time, because god forbid they organize themselves) instead of focusing on the proposal.

I don’t think a longer review time will do anything at all to solve this problem because most of our proposals never make it to review anyways.

Robert

--
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/266e4a22-dcb0-4008-8414-17c40501e9ae%40googlegroups.com.

[Pádraic Brady]

On 15 October 2014 20:35, Robert Hafner <ted...@tedivm.com> wrote:

The problem is, in my opinion, that there are two many cooks in the kitchen and many of them care more about driving traffic to their blogs than they do about this group (hence why I’m not surprised this “open letter” was not even sent to this group directly until someone asked). 

This is a public group, so having too many cooks is not actually the problem...it's the intended goal. It's important to differentiate between the result of running a public group that invites random people to comment and the process through which those comments are managed. One of these things is intentionally unsolvable.

 

Here’s the cycle I see-

1. People find a need- such as Logging, Caching, or HTTP Messages- and it gets some sponsors.

2. Proposal gets written, and a dozen or so people spend their time tearing it apart and making it better.

3. Random person enters, tears apart proposal based off of misunderstandings.

4. People work with Random person, show them why things work the way they do, and get them on board.

Which is a problem of process. The meta document is intended to prevent re-treading old ground by ensuring anyone who reads it knows what has or has not been decided. All decisions presumably being final and closed to debate - end of story. The outcome should therefore be telling random people who bring up old arguments to read the frickin' thing and go away. Perhaps slightly more diplomatically :). If they raise a genuine, never before seen, argument or debate point, then engaging with them is worthwhile to tease it out and make a decision - so you can update the meta document for that new point and put a stopper on it if ever repeated. Assuming the point is both valid and valuable, and not simply nitpicking...

 

5. Work continues for a bit, and we think we’re getting close.

6. Return to 3.

Refer to meta document.

 

7. Return to 3.

Refer to meta document.
 

8. Return to 3.

Refer to meta document! ;)
 

Frankly, we have a bunch of people who are not at all engaged who randomly pop in and decide it’s the most important thing ever, then we spend our time trying to educate them (one at a time, because god forbid they organize themselves) instead of focusing on the proposal.

If significant time goes into this, then someone other than the random people are agreeing on its importance, unable to point to where covered in the meta-document, or incapable of resisting pointless engagement. That will reinforce the random person's motivation to continue their course of action unimpeded which may be justified if their point is not covered, or unjustified if it was previously documented or is just too minor to have a consequence on the PSR draft.

 

I don’t think a longer review time will do anything at all to solve this problem because most of our proposals never make it to review anyways.

Additional review time will solve nothing unless we can improve engagement with the people who actually pass PSRs, i.e. the voting representatives. That's always going to be a function of their interest, available time, and the quality of communications from the Editor who represents the PSR to the group in providing updates, encouraging review, etc. More time is not a substitute for this - there's already been weeks/months to get representatives' feedback. The review period is basically a final notice for them to get it done before voting. There is some onus on the representatives to give an informed vote so presumably they're going to review it before doing so. They only have themselves to blame if voting is underway and then they decide to look at it.

Paddy

--
Pádraic Brady

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

[Bret Mette]

You learn 100% of what you teach. Maybe hashing it over a bunch of times and explaining it to randoms is not the worst thing to do before it gets accepted and set in stone.

This forum was created public by design. These conversations could have been left private witout the seemingly mindless chatter of the peanut gallery. While most of time they may appear fruitless, you never know when an idea will spark from them.

If anything it serves as a good round of testing to help bring buried issues to the surface before voting.

With that being said, I do feel your pain and often times these threads are growing out of control. I think there are multiple reasons for that and it looks like the community wants to address it.

- bret

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/A675134E-9961-42CF-9DC5-27CAECECBEBF%40tedivm.com.

[Philip Sturgeon]

For the record, I hold Anthony to a different level as the randoms who waltz in and f**k everything up with their poorly thought out complaints. 

I'd suggest that his concerns are a little different to the average DURP I DONT LIKE CACHE ITEMS that we've had a few times now.

Apparently Larry hasn't read this yet. I'd suggest you all read it twice before commenting further. :)

[Jae Lee]

Hi, guys, pardon me for jumping on this discussion but I have a quick question if you could please answer.

Do we really need FIG? (Like really really?)

I understand frameworks would love to just swap out different libraries here and there, but does it really have to be like hot swappable? If it's to save time then perhaps you shouldn't even be working on a framework?

As a PHP guy, I think I can care less. I just want quality packages and I'll code 'my' framework to use that package, not the other way around.

Really, I just want a better packaging system in PHP, I really do. For a language this old, it's still horrible (utter crap). Yea there's composer but it's like it tried to create a - rocket out of a pencil. Whatever the design decision was, it didn't start off from simplicity in mind. (I kinda hope this group can focus on that area of PHP more)

And you guys might already know this but there is just a lot of drama here. I mean like HBO level drama.

It's actually scary sometimes.

Makes you wonder, you guys are set to create FIG (equiv. of world peace) but with this much fighting, are we asking for too much?

A concerned PHP dev,

JL

--

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/917e6897-d231-4cc5-afd7-91811fb71036%40googlegroups.com.

[Korvin Szanto]

aaaaaaand we approach irreducible complexity, Ruby-FIG anyone?

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAGi6E9GS-%2B0n6EXb7CbzfTt0TMvdvFZAPGXWQhFXWc9MQvRhkA%40mail.gmail.com.

[Alessandro Pellizzari]

On 2014-10-16 01:17, Jae Lee wrote:

> Hi, guys, pardon me for jumping on this discussion but I have a quick
> question if you could please answer.

Hiya, mr Nobody here. :)

> Do we really need FIG? (Like really really?)
> I understand frameworks would love to just swap out different
> libraries here and there, but does it really have to be like hot

> swappable? If its to save time then perhaps you shouldnt even be
> working on a framework?

I think the main target of FIG should be (and is) the "final user".

I mean: defining standards means that all the frameworks will have more
work to do to adhere to those standards, so it's not in their immediate
interest to define standards they don't already implement.

It's the framework user that's going to benefit from that.

For example, if I am using FW1 but it's logger is crappy and limited
and doesn't allow me to save logs to a remote rsyslogd in a docker
instance on AWS and I want to use FW2's, and my app uses DI, I can just
swap the logger in the bootstrap.php and I'm done.

The same for caching systems, request/response, etc.

I think the main concern when defining interfaces should be for the
final user, as Anthony says. All the discussion should be (and generally
are, from what I see) to define a minimum usable interface.

Bye.

[Lukas Kahwe Smith]

imho it would be better to have a dedicated work group on a read only mailinglist for everyone else. anyone that wants to join (regardless if member or not if FIG itself) may join by asking on the main list. it is expected that these people have familiarized themselves with what has been discussed so far. and its then up to the working group to decide if they want to admit another person. any proposal must have X number of feedback rounds (maybe we should define a minimum of 2 feedback rounds), where the mailinglist is opened for anyone, who can then comment for a defined period (lets say 2 weeks).

while this might make it harder for some people to give their spur of the moment feedback, imho it will ensure that discussion do not go in circles and the working group doesn’t waste its time on clearing those up. I continuously see a pattern where details around misunderstandings blow up into dozens of emails within a few hours, which is imho really killing efficiency and therefore motivation.

also if in the end the proposal does not convince the members of FIG, then so be it. lets rather have more vote worthy proposals, than endless discussions. imho this will lead us more towards solving the 80% or 50% case .. rather than trying to provide kitchen sink solutions.

[Phil Sturgeon]

Wherever you put it, you’re always gonna have random people dive in and alternative propel bomb you. 

We currently have small working groups and they do discuss things in threads with [Cache] at the front, so those that don’t care  don’t have to look. It’s not very different either way.

-- 
Phil Sturgeon
Sent with Airmail

[Dracony]

As for me, I'd say FIG definitely needs some mandated PSR-only chat sessions. The mailing list is cool and all, but it seems that the discussion is usually to dynamic for that medium. Especially when it comes to PSRs.

This would also make sure that as many members as possible participate, and not just the usual 5 or so. This would get a lot of going around in circles out of the way and would also make mailboxes cleaner =)

as an added bonus it would provide a nice track record for members, and it might be even possible to add a bylaw that a project may get expelled if it misses a set amount of meetings.

this might be hard because of timezones, but if those meetings are like once a week it shouldn't be such an issue. Also it may be possible to have 2 meetings in alternating timezones, so a person could join the one that fits best.

[Anthony Ferrara]

All,

I have followed up with a technical blog post detailing technical points around the stance of the blog post that I posted a few days ago: http://blog.ircmaxell.com/2014/10/a-followup-to-open-letter-to-php-fig.html

But I also wanted to clarify a few things directly here.

I have quite a bit to say, so please forgive the verbosity of it:

## Why Was It Not Posted To List?

Some people want to know why I posted this on my blog rather than to this list.

There are two main reasons that I chose to do it as an open letter:

1. I think the community as a whole can benefit from the message.

    That's not just FIG, but every framework developer. Every library developer. Etc.

    It's a universal concept. I feel that too often framework and library developers tend to overcomplicate things to try to fit all use cases. Heck, that even becomes a selling point.

    So it's an open letter, because the FIG has something specific they can action, but the lesson is important for everyone.

2. Have you followed discussions on this group lately?

    They tend to get lost in rhetoric or derailed. 

    Heck, this very post was derailed several times. Yes, there are are some very good replies. But out of a thread with 21 posts, half of them miss the point completely.

    So by making it an open letter, it can be more of a focus, and the message has less chance of being lost in the wind.

## Why Don't I Write My Own Standard Proposal?

This is a very valid question.

It boils down to time. I personally am not scalable. I have enough projects that I'd like to get done that I don't have enough time to do any of them (yet alone all of them). That's why my blog has been inactive this year.

I think the people here in the FIG are quite capable. I do have faith in you.

I don't think it would be constructive nor needed for me to write a bunch of proposals.

Instead, I just wanted to give a nudge in what I perceived to be the right direction when it seemed to me that the group was getting off track.

I provide as much help as I can. People on this group have asked for help in the past, and I have done everything I can do give it. But I am not a visible contributor simply because there's only one of me, and I can't be everywhere at once...

Additionally, I think it could use some serious reflection the way some people have responded to this. 

One thing that strikes me, is that it's been mentioned several times about how people "keep coming in and tearing proposals apart based on misunderstandings". Perhaps that is their problem. But perhaps that's a sign of a deeper problem. If there are that many people with that strong of misunderstandings, perhaps there's a problem with the proposal.

In one of the threads, a very particular sentence was used:

 > You are simply wrong, and had you actually taken the time to discuss things with me I would have showed this to you.

So was I wrong for not trying to discuss things on list...? But not because my input was or wasn't valid, but because I was wrong, and wasn't given the chance to be shown that.

Seriously? Constructive much?

Also, I am extremely saddened by the talk of private chats in this thread and as of late. If you can't find a way to be constructive in the open, going into private is simply going to make things FAR worse. 

I hope that provides clarity and direction. And clears up a few misconceptions. Ultimately the way you go forward is up to you. I just hope you can take this as constructive criticism, and consider what I've said.

Anthony

[Philip Sturgeon]

So, while I am not blindly suggesting we ditch everything and switch to something like Anthony's proposal, I would beg you to conisider it seriously.

His first open letter was rather short on examples, and ass such to me was - sorry mate - a little useless. To be fair he was talking in generalities using the cache stuff as an example, but the focus ended up being on the cache system. 

His new letter intentionally focuses on the cache proposal and does it well. While it looks once more like "strong v weak items", its actually not that. It's more "composition v extension," and when the argument is placed like that, it ends up taking care of everything we need without needing strong items.

Fail value is false, -1 or null

Cool, who cares, we just specify that we want a null if the value was not found. Driver based systems can check for false if they know false is their fail value, and return a null. Mention we dont allow null values to be stored. Okie doke.

Tagging and stuff

The item class has been explained as our aim to keep this simple. We will define this item cache, which in the future will allow developers to add in their own namespaces, group invalidation, tagging, etc. We don't currently have any of that, but the plan was to let the group build this TTL stuff, then see what the rest of the community does with these cache extensions and standardise THAT too, later on.

Well, if composition is used then we dont need it!

I would - as Anthony suggests - rather see small, simple interfaces, that can all be in lots of little PSRs. We can have CacheStampedeInterface which is a PSR for how you handle cache stampedes, instead of this mega-massive PSR-5 thats taken almost 4 years. 

I know changing things around is a great way to make things take longer, but at this point I have to wonder if its taking so long mostly because its so big and complex. 

I'm not decided either way here, but I do want to see a discussion, We definitely should not just throw Anthony's concerns and points in the bin because they look similar to those made by idiots in the past. :)

[Alexander Makarov]

He-he, that's what the name does ;) I was talking about the fact that exactly that simple interface w/o object wrappers will handle everything well quite long time ago and recently Rasmus Shultz did. In both cases we were attacked aggressively enough by majority of voting members to give up. I still prefer non-wrapper simplistic approach so if it's still possible to get back to simplicity I'll definitely support it instead of complex stuff not that many project will understand and adopt.

[Alessandro Pellizzari]

On Sun, 19 Oct 2014 08:29:14 -0700 (PDT)
Philip Sturgeon <pjstu...@gmail.com> wrote:

> So, while I am not blindly suggesting we ditch everything and switch
> to something like Anthony's proposal, I would beg you to conisider it
> seriously.

I honestly like it much more than the current proposal. I thought
before his post that the current proposal was "wrong" but couldn't
understand why and how to make it simple. His post was eye-opening.

> I would - as Anthony suggests - rather see small, simple interfaces,
> that can all be in lots of little PSRs. We can have
> CacheStampedeInterface which is a PSR for how you handle cache
> stampedes, instead of this mega-massive PSR-5 thats taken almost 4
> years.

As for the cache stampede, I thought of something that would work with
the simplified interface and would like your (of the group) opinion on
that.

Simply put: the cache engine returns null on the first request for an
expired item, and returns the previous value until a new setValue() is
called.

This way the process receiving null will regenerate it, and
subsequent processes can continue to work with old data while that
process regenerates them.

This would allow to keep the interface as simple as possible (as
Anthony proposed) and manage everything under the hood on the
implementation.

Bye.

[Philip Sturgeon]

On Sunday, October 19, 2014 11:34:04 AM UTC-5, Alexander Makarov wrote:

He-he, that's what the name does ;) I was talking about the fact that exactly that simple interface w/o object wrappers will handle everything well quite long time ago and recently Rasmus Shultz did. In both cases we were attacked aggressively enough by majority of voting members to give up. I still prefer non-wrapper simplistic approach so if it's still possible to get back to simplicity I'll definitely support it instead of complex stuff not that many project will understand and adopt.

What Rasmus was suggesting was not at all the same as what Anthony was suggesting. 

Anthony is suggesting simplifying the interface by using composition to remove the need for extending a cache item. This makes things easier for the end user, more simple to implement for cache developers and easier for us to release as a standard.

Rasmus was suggesting keeping exactly what we have now, but adding "Driver Interfaces" as well as that. This would force the implementation to be even more specific. That in turn makes it harder to use for the end user, more difficult to implement for cache developers and even harder for us to release as a standard.

So, yeah, a bit different. :)

[Matteo Beccati]

Hi,

On 19/10/2014 18:59, Alessandro Pellizzari wrote:
> On Sun, 19 Oct 2014 08:29:14 -0700 (PDT)
> Philip Sturgeon <pjstu...@gmail.com> wrote:
>
>> So, while I am not blindly suggesting we ditch everything and switch
>> to something like Anthony's proposal, I would beg you to conisider it
>> seriously.
>
> I honestly like it much more than the current proposal. I thought
> before his post that the current proposal was "wrong" but couldn't
> understand why and how to make it simple. His post was eye-opening.

I agree. I'm not saying that whoever worked on PSR-6 did a bad job.
Actually, I truly appreciate all the efforts that have been
made to get it where it is now, but I'd be in favour of considering a
switch. I might not 100% agree on what Anthony suggests, but I think
it's a good starting point which does not limit the users freedom or
bind them to very specific implementations.

> As for the cache stampede, I thought of something that would work with
> the simplified interface and would like your (of the group) opinion on
> that.
>
> Simply put: the cache engine returns null on the first request for an
> expired item, and returns the previous value until a new setValue() is
> called.
>
> This way the process receiving null will regenerate it, and
> subsequent processes can continue to work with old data while that
> process regenerates them.
>
> This would allow to keep the interface as simple as possible (as
> Anthony proposed) and manage everything under the hood on the
> implementation.

That matches what I was suggesting a while ago and also matches most of
the real world scenarios I've ever seen in and out of the PHP world. My
suggestion was rejected because "expiration MUST be hard, regardless".
If PSR-6 is reset, and some TTL support is added back, that is one of
the things I'd love to see change.


Cheers
--
Matteo Beccati

Development & Consulting - http://www.beccati.com/

[Alexander Makarov]

Nah, Rasmus *initially* suggested no-wrapper approach. Then when he received a portion of "it's already set in stone by voting" he suggested something else.

[Jeremy Lindblom]

Thank you Anthony, especially for the follow up post. You've presented extremely valid and logical points. I agree with your analysis of the cache PSR, and I too think we should adopt something simpler like you've suggested. I've already voiced my opinion about that before, but I lack the time and arguing skills to effectively voice my opinions.

I wanted to respond to a couple of comments.

Phil said (and I agree with him):

> I know changing things around is a great way to make things take longer, but at this point I have to wonder if its taking so long mostly because its so big and complex.

I'm not sure if anyone has noticed, but the entire last year of the cache PSR has just been people asking, "Should this method go on Item, Pool, or both?", over and over. This, too me, has been an indication that we've gone down the wrong path. Instead of finding clarity, we've found ambiguity. I really do appreciate the time and effort of people like Robert, Paul, Larry, and others have put into working on this though, even if I don't necessarily agree with all the choices. These are all people that have more experience than me dealing with caching. However, as Anthony has demonstrated (quite well), there are ways we can do a cache PSR that keeps things simple, but does not hinder the advanced cache use cases.

Here's another comment by Phil that I think deserves some clarification:

> Rasmus was suggesting keeping exactly what we have now, but adding "Driver Interfaces" as well as that. This would force the implementation to be even more specific. That in turn makes it harder to use for the end user, more difficult to implement for cache developers and even harder for us to release as a standard.

Actually, Rasmus originally came to criticize the Pool/Item proposal and ask for something simpler. He came across quite brusquely though, and got permanently flagged for that. His simple proposal (for which I also posted a similar idea) was rejected outright (unfairly, since it did provide at least one new idea—get($key, &$found = null)—that nullified some content in the meta document). After being rejected, he tried to compromise by switching his idea to an additive Driver interface, instead of a replacement. That idea, I agree, was not very good, but it was not his original intention.

Anyways, thanks to the people working on the Cache PSR (and other PSR). But thanks to those who come in and stir the pot, too (in this case, double thanks to Anthony). Let's make things to help the community, but let's also keep it simple... and civil.

[Philip Sturgeon]

On Monday, October 20, 2014 1:05:40 PM UTC-4, Alexander Makarov wrote:

Nah, Rasmus *initially* suggested no-wrapper approach. Then when he received a portion of "it's already set in stone by voting" he suggested something else.

I at first thought he was suggesting Strong v Weak. He said it was always about his driver approach. I guess I never know what is going on with him. His tone screws with my ability to be cool with him. 

When his suggestions did look like Strong v Weak,  like various that have come before, he did not do the good job of suggestion composition to take care of the functionality that the weak would lose. 

It's very easy to say "Just get rid of cache item objects!" and ignore the reasoning we had them there in the first place. If you can instead say "Here are some alternative ways to get the same functionality, that invalidate the requirement for cache item objects" like Anthony did, then I am all ears. 

As Jeremy said, Anthony is not the first person to have ideas about a weak system, but he has presented arguments and examples more logically than anyone has previously. That is why I am listening to the suggestions.

I am disinterested in any sort of "WELL THATS WHAT BOB SAID" which may have come before that. :)

[Filipe Guerra]

Hi everyone,

Let me start by saying that I've been away of these discussions for a while, due to several reasons not worth mentioning here.

I would like to know why we keep wasting energy with these posts instead of finding good solutions for everyone.

Meaning: while I tend to agree (or understand) Anthony's point of view, I do not agree with the simplified version that he mentioned in his blog and, probably I misinterpreted it, but I also didn't read it as an attack for any PSR in general or the group, but more like an opinion.

All I can say is that we are doing what he said (at the end):

> As simple as possible, as complex as necessary.

Afaik, no PSR is currently accepted/approved that doesn't do that. I believe everyone is working hard to balance exactly to be as simple as possible and as complex as necessary.

Let's take the PSR-3 (already approved) as an example. While Anthony gave his opinion about it, the representatives of PHP-FIG decided that it had to be more complex than a simple log() method.

Why? Read the discussions around it first!

Keep in mind that you can always create a null logger (that information is stated in the PSR-3), and therefore you can also "not do anything" for that method. Basically the projects that we represent want to use $logger->debug() instead of $logger->log('debug', ...). That said, it was decided to create the current interface (which representatives voted and agreed with - met the quorum).

It is also important to mention that no one is required to follow/implement a certain PSR and go your own way, in the same way that you aren't obligated to use a design pattern, you can do your own crap! (and maintain it)

For the current PSRs still in approval, I don't see why we are bringing such drama and rampage on them. I say: "Is it good enough for most of the ppl (that care about it)? Then call a vote for it.".

That is when ppl can vote "-1" and if we meet the quorum, get it approved even if some ppl aren't pleased with it.

For other ppl that can't vote and don't agree, well you can always complain and maybe there will be someone that propose and sponsorship a new PSR, that then can be proposed and we can deprecate the old one (just like PSR-0).

What would be the internet if we kept using HTTP/1.0 with no standard about Keep-Alive? That doesn't mean that you couldn't use it on 1.0! But now we have a standard!

My point on this is simple: in the same way that Anthony said that we can have an interface Transaction extends CacheAdapter, to keep CacheAdapter simpler, I say it works in the opposite direction too and you can simple do:

public function commit() {

    // do nothing because my crap is too simple and I always commit stuff automatically

}

Same applies to TTL. Don't support it, sure put in that method that you don't care about the TTL for your cache (just don't complain after that you forgot to implement something).

BUT, at least if you implement it, then it will be consistent with everyone else that supports it!

The idea of the PSRs is to find a common ground/interface to solve the simple and the complex problems (as needed/possible) - again "As simple as possible, as complex as necessary". For everything else it is agnostic (like PSR-2 is agnostic on how to format arrays and a bunch of other stuff that sometimes is mentioned in this mlist).

Again, the group is doing everything right as long as the projects that are represented achieve the required/agreed level of interoperability.

E.g: SugarCRM is using a shitty logger that is PSR-3 compliant and sees this great Monolog project... DANG it is so easy to swap it! Tomorrow there is a new PSR-3 compliant logger that does more stuff that we want... DANG swap it! That is why the PSR-3 was created, so we don't have to create stupid adapters to map the methods that we had!

Composer allows us to swap stuff easily too due to PSR-0 and now PSR-4! Great!

Let's please direct our energy in stuff useful and focus in our group goals.

Regards,

Filipe Guerra