Async Standards Body

[assertchris]

Let's discuss a seperate standards body, for async interoperability, here.

[WyriHaximus]

Coming from #5, the interface suffix shouldn't be the reason by a long way to do this. Would love to hear some pros and cons for the FIG and ASB to house these standards.

[assertchris]

For the record, I am not opposed to this idea. I think it such a group should be created with inspiration from the recent FIG discussions that have been going on (in terms of representation, voting etc).

It would be a way for us to address the lack of consideration, for async stuff, in existing PSR's. We're never going to get 100% buy-in for amending existing PSR's to allow for deferred types etc.

Edit: PSR 7 defines scalar return types for everything. But requests and responses can have stream bodies, which behave asynchronously. PSR 5 doesn't mention asynchronous types beyond Generator. Nothing to say that a method is a @coroutine or what an awaitable method will @resolve to... PSR 3 defines scalar return types for logging operations, but the write operations could also be asynchronous.

Edit: Such a thing could even serve as a way for FIG to see the different structures they have been discussing applied to a standards body.

[kelunik]

Pro:

• All current FIG PSRs are synchronous and all I/O related PSRs would need an async counterpart
• It might be confusing if there are two versions of each PSR under FIG
• Async and sync PSRs would be grouped

Contra:

• FIG has already an established process and bylaws

[WyriHaximus]

For the record, I have no opinion nor side for idea yet but I'm not opposed to it.

One of the things with PSR-7 is that while streams can behave depending on the case trickery mentioned in #9 might have have to be used to achieve compatibility. Would create complementing standards be an idea where PSR-7 would be adapted to be fully async compatible.

[cboden]

An issue I see having async in FIG is there's a very good chance a lot of the voting membership will not have an understanding of async.

[WyriHaximus]

Or see the importance for of async related PSR for that matter.

[kelunik]

@WyriHaximus PSR-7 is not in any way compatible with async.

I think @cboden is right and there are many voting members without any understanding of async.

[WyriHaximus]

@kelunik Not it isn't by a long shot but can be molded into behaving like it.

There are a few in the FIG that absolutely love to see async PSR's. But that is the same group that is highly visible in the community for the FIG. Haven't seen a lot from the other members. (Correct me if I'm wrong.)

[bwoebi]

@WyriHaximus no, I tried it, but I absolutely wasn't able to make it async (especially the body requires for example all data being collected first before request starts), not going to work with Promises etc.

Also, we'd eventually be able to define our own @phpdoc annotations which IDEs will understand (like a generator marked @coroutine will upon $val = yield $promise; result in the generic type of the Promise (if we have @return Promise<ParsedBody>)

@kelunik I doubt we'll be able to have a meaningful asnyc PSR-4 :-P (just kidding)

For the record: I'm not opposed either.

@WyriHaximus while there are a few who'd like to see more async, there still aren't many who also understand async, as @cboden said.

There's another advantage @kelunik missed: Only people who actually understand async will also vote on asnyc standards. If we go via FIG, we might either have problems to reach quorum, have many ±0 votes or many "nice, I want async, looks good" +1 votes or many "I don't understand async and this makes no sense to me" -1 votes.

[WyriHaximus]

@WyriHaximus no, I tried it, but I absolutely wasn't able to make it async (especially the body requires for example all data being collected first before request starts), not going to work with Promises etc.

Hmm you have a very valid point there, haven't dealt with asyncly uploading files using PSR-7 tbh. But lets not stay off topic to much.

@WyriHaximus while there are a few who'd like to see more async, there still aren't many who also understand async, as @cboden said.

I was attempting the further strengthen @cboden's point no go against it :).

There's another advantage @kelunik missed: Only people who actually understand async will also vote on asnyc standards. If we go via FIG, we might either have problems to reach quorum, have many ±0 votes or many "nice, I want async, looks good" +1 votes or many "I don't understand async and this makes no sense to me" -1 votes.

That exactly is what I'm afraid of, of course we would have to propose the PSR with an entrance vote before putting the PSR up for acceptance vote. I can see it go in any direction...

[bwoebi]

I'd be surprised when entrance vote would fail … but especially for acceptance votes FIG votes might be not helpful at all. What's the point of a vote if you don't understand what is being voted on!?

---

I propose we now try to make this an interface we can all agree on - and then when it would be time to go FIG, we revise whether we still feel this way and eventually form a separate entity. That way we also don't take this decision in hurry and can concentrate on the important topics regarding the interface.

[assertchris]

Would it be fair to say that we can ignore "consistency with existing PSR", especially when it comes to the "Interface" suffix?

[bwoebi]

Yes, that's what I meant: do our "own" thing for now (the way we prefer it etc.) … and then, when it's about time, discuss it again. Should be fairly easy to make it "FIG-compatible" if necessary.

[WyriHaximus]

Sounds like a good plan to me :+1:

[AndrewCarterUK]

The github organisation we have set up here was designed to decouple ourselves from the FIG process so that their politics wouldn't affect our progress. I'm happy to discuss ways in which we could adapt this into a standards body on its own. The main argument against this is that FIG PSRs would probably introduce more people to the work that we are doing.

[bwoebi]

I'm sure though people really interested in async will come themselves here.

[davidwdan]

I'm in favor of a separate body that's unencumbered by FIG. FIG would provide more exposure, but my fear is that Async PHP will always be treated as the "red headed stepchild".

[michaelcullum]

I'd like to have a google hangout in which we can discuss this further, who would be interested in joining me for that?

The new direction the FIG is going in is to be a PHP standards body, and the specifications it creates I imagine are going to cover a great number more things. Async proposals have a place in PHP, and therefore should have a place in the PHP standards group (the FIG) and it's certainly something we should consider as part of the restructure. One unified standards body greatly simplifies things and having alternative standards bodies will only complicate getting the message out, everyone benefits from having everything under one roof in the increased exposure and we can ensure that we are solving problems once (As a standards org, no matter what you hit politics or process organisation). The PHP community is just beginning to come together, and fracturing that I don't think will be conducive to any involved. The main issue that appears to be a sticking point for people is dealing with the problem of people not understanding the specification and this is a point we're already working hard to address as this doesn't just affect async, but every proposal that goes through the FIG (With some exceptions such as maybe PSR-1/2/12) with the new working group and core committee structure, so essentially removing the 'all member projects have a say' on individual PSRs acceptance votes. The most important vote is that of the working group, which is of parties who understand the proposal and relevance.

There is also the issue of 'updating' specifications and I discussed this briefly with David Zeulke who, at the FIG's inception suggested we use 100, 200, 300 etc. for specifications then use latter numbers within that century for specifications in the same problem space (So PSR-0 would have been PSR-100 and PSR-4 would have been PSR-101). This isn't something we can really adjust to now but creating new specifications to extend existing specifications (As PSR-2 does) or replacing specifications (As PSR-4 and PSR-12 do) is totally fine and something I expect to see more of. This is how the IETF does things and it works pretty well.

I agree that right now having the async-interop group makes sense in that you can work on your specifications whilst the FIG works on it's restructuring process, but afterwards I'd really like to see it reabsorbed into the FIG and essentially you'll still work very similarly as you do now in the new working group structure.

As a note, the whole interface class name suffix is something we can just change in the FIG, and I'd be slightly disappointed to see this as a reason for splitting off before it's even been proposed and gone to a vote. We can bundle it up with some other upcoming bylaw changes if need be.

[bwoebi]

(I'm btw. not so much a fan of hangouts with more people :-( But I'd happily join a chat.)

@michaelcullum So, basically, it'd be a standalone group working under the name of FIG and publishing PSRs, but that'd then would be point where integration ends? Well, I think that's what we actually wanted.

Regarding updates I'd rather have "The second version of the Autoloading Standard" than "PSR-101" … At least after a while numbers become meaningless. I see that well with RFCs "RFC 6455", "RFC 7230", "RFC 2616" … or would you prefer to talk about "Websocket Standard", "HTTP/2 Standard" and "HTTP Standard" respectively? ;-) The only ones knowing the numbers by heart are those who intensively worked with/on these specific RFCs.

Also independently I'd be happy if these bylaws regarding suffixes were changed in general. (It's definitely not the reason for why we'd split up, just what ultimately initiated the discussion.)

[michaelcullum]

Indeed. Numbers even now we are at 13 have come confusing for people so names will become increasingly important.

The current, very rough and very summarised idea is that the working group works on the standard, votes on it (2/3 majority), then it goes to a core committee (CC) which is a very small number of individuals (not projects) who do a final stamp of approval and quality assurance kind of thing. They'll make sure the WG have done due diligence in producing the spec and that it is of a good standard with at least two written implementations. They are more of a checking mechanism whereas the technical detail is more for the WG and it will never even get to the core committee if the WG (entities that know what they're talking about) have voted on it. The CC is basically a keeper of the FIG's quality image, the WGs make the specs work and ensure the specs are good specs and the member projects just give the FIG more weight, but have much less day to day involvement.

[bwoebi]

Yes, that looks like something I could imagine to work with.

You seem to already have some more specific ideas about how that is going to work … is there already any draft proposals or discussions around that I can follow? [Precise responsibilities, creation of working groups, etc.?]

Not sure though whether we need two written implementations or one with an extensive testsuite (which will also be applicable to other interface implementators) is enough?

[AndrewCarterUK]

@bwoebi - There are enough async projects behind this proposal that we could definitely get two written implementations. Ideally we want more, by people who haven't worked directly on the specification (this is the best way of finding problems).

[michaelcullum]

@bwoebi Not yet. We're still assessing all the problems people have with the FIG and drafting up plans that fix those problems. Hence my eagerness to have a hangout with you guys.

[sagebind]

One unified standards body greatly simplifies things and having alternative standards bodies will only complicate getting the message out, everyone benefits from having everything under one roof in the increased exposure and we can ensure that we are solving problems once

I very much would have to agree with this stance. While it makes a ton of sense to set up an async interop group, I would say doing so isn't at odds with being part of the FIG. Think of it as a "team", if you will, of those who specialize in async and can focus on async standards.

[assertchris]

Here is the recording of the hangout where we discussed it further. @squinones has supporting notes.

Perhaps I can summarise (and close this issue) by saying that we'll continue work on this PSR until such time as we have something that we feel is in a fit state to take to an entrance vote. At that point we'll re-assess whether the FIG restructure is complete and satisfactory for us to introduce this PSR there. We are hopeful that this will be the case, and will contribute to discussions (there) to make this happen.

Thanks to everyone who attended, and has thus far been involved in the conversation.

[michaelcullum]

Sorry for not posting the notes: https://docs.google.com/document/d/1BwVfemoGva-tlBum_q3LDpX1mlVteWzNRHJH-Ldlq0g/edit?usp=sharing

[kelunik]

Reopening as we're getting closer to a stable standard. Do we want this to become a FIG standard or keep async standards outside of the FIG?

[michaelcullum]

FIG 3.0 will be going to a vote probably towards the end of this month FYI.

[bwoebi]

So, let's best wait for FIG 3.0 to pass before continuing discussion about this, I think.

[kelunik]

@bwoebi What does 3.0 actually change here? It changes workflow internals, but I don't think it will change whether we want to have this standard be a FIG standard or not.

[geggleto]

I have a feeling 3.0 might never pass, having a standards body for this group isn't a bad idea.

[WyriHaximus]

I have a feeling 3.0 might never pass

Looking at the current state of the FIG, that looks very likely

[davidwdan]

I can't say that I'm a big fan of v3.0 or the direction of the FIG in general.

Like I said before, I'm in favor of a separate body that's unencumbered by the FIG. This doesn't mean that standards can't be submitted to the FIG or a new PHP standards body, for acceptance if or when it makes sense to. It does mean that this group can do whatever it wants, however it wants, without any unnecessary politics or overbearing "oversight".

[kelunik]

This doesn't mean that standards can't be submitted to the FIG or a new PHP standards body

If we want to do that, we have to follow their rules, e.g. #96. If we choose to keep it separate, I think it makes sense to keep it entirely separate.

[michaelcullum]

@davidwdan The FIG 3.0 proposal was discussed in a meeting a while back between FIG secretaries and most of the async folks and it was concluded FIG 3.0 should work well to represent interests of async folks (a lot of FIG 3.0 is tailored specifically towards async stuff being able to be done properly). At the moment, there is only 1 voting member who has said they'll vote -1 on FIG 3.0 so I think it's a bit early to cast aspersions that FIG 3.0 will never pass. ;) Let's see what happens, then this discussion can be continued and you folks can work out what you want to do.

[kelunik]

FIG 3.0 has passed. What's the way forward now?

[michaelcullum]

Just a note to say I've seen this and will write up a more comprehensive reply in the next couple of days.

[joshdifabio]

A couple of other things worth considering:

1. It seems that FIG PSRs must only contain fully abstract classes/interfaces at present. (Consider async-interop/event-loop.)
2. As far as I can tell, the core committee, which will consist of 12 members, and which will be "responsible for final decisions regarding what specifications FIG will consider and those that are approved," will contain at most one person who is active in the PHP async community (@WyriHaximus has been nominated).

[michaelcullum]

Regarding point 1. That's not true. PSRs can contain anything that you guys/the CC decide is appropriate. It's just only been interfaces in a lot of standards.

[michaelcullum]

We also have some official PHP fig packages (see fig/*-util) packages which can change after specification publish dates for bug fixes, new conservative features etc.

[kelunik]

Just a note to say I've seen this and will write up a more comprehensive reply in the next couple of days.

ping @michaelcullum

[kelunik]

I'd like to sort this one out sooner rather than later, otherwise we end up with a finalized spec and this one still open. @bwoebi said he'd like to stay separate, but maybe officially acknowledged by the FIG.

[assertchris]

Personally more interested in @bwoebi remaining interested and willing to contribute than bringing things under the FIG umbrella. I'd side (for lack of better phrasing) with any of the active people here over moving to FIG, because of the demonstrable value this project has brought to the topic without much FIG involvement to date.

[michaelcullum]

It was my general understanding that consensus of all present after our google hangout earlier in the year that with the new working group structure (FIG 3.0) it was agreed that async interop could move under the FIG umbrella at that point for the numerous benefits (to both the FIG, the wider async and non-async php community and you folks) discussed in that meeting and lack of benefit to operating outside the FIG (As it was generally agreed the previously reasons on why the FIG was bad for this should be nulled with the new working group structure). async-interop was also often cited by both async-interop members and external people as why the FIG should move to a working group structure and why the WG structure works. If it doesn't work with async-interop operating under the FIG (as container-interop does/has/will) then the FIG 3.0 process is broken and we should probably try and work together to improve it.

If people have changed their minds on how to proceed, lets grab another time to hop on a hangout to discuss this. I apologise for not responding earlier to this, I believed it to be more about how would we go about moving async-interop into the wider FIG as opposed to 'should we or not'; and therefore was not time sensitive as until the full FIG 3.0 transition at the beginning of February there were no immediate steps to take so I hadn't put time aside to write something up about the process.

[michaelcullum]

If people would prefer against having a hangout in the new year I can try and put together a reasonable length reply about the benefits (for all verious involved parties) and resolved cons (resolved by FIG 3.0), but a conversation would prove significantly more efficient (as async folks, I'm sure you understand that more than most if you get my meaning).

[assertchris]

To be clear: I like the FIG, and want to see it succeed in its goals. I'm not saying I'd personally prefer for this stuff not to be there – I've described this work as an off-shoot of FIG, and as part of it, in the past – I'm saying I'd much rather have the people who are active remain active. I'm here in support of the folks doing the actual work, and in promotion of it elsewhere.

[kelunik]

@assertchris We won't disappear just because async-interop just joined the FIG.

[kelunik]

@michaelcullum Usually I say that naming isn't that important, but the Interface suffix requirement really bugs me for promises. It's already annoying to alias LoggerInterface to Logger or PsrLogger in every file that uses it, but it will be even more annoying to alias PromiseInterface in each and every file, as nearly every file will use it as a return type declaration. It's something FIG needs to fix but is not willing to do, as we saw in the recent vote. It's a super stupid requirement.

[hikari-no-yume]

Some languages use just I, would that be better?

[kelunik]

@TazeTSchnitzel It's shorter, but not really better. A consumer shouldn't even care whether it's an interface or class.