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 👍