event-loop
event-loop copied to clipboard
async-interop
Async Standards Body
Let's discuss a seperate standards body, for async interoperability, here.
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.
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.
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
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.
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 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.
@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.)
@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 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...
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.
Would it be fair to say that we can ignore "consistency with existing PSR", especially when it comes to the "Interface" suffix?
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.
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.
I'm sure though people really interested in async will come themselves here.
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".
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.
(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.)
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.
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?
@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).
@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.
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.
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.
Sorry for not posting the notes: https://docs.google.com/document/d/1BwVfemoGva-tlBum_q3LDpX1mlVteWzNRHJH-Ldlq0g/edit?usp=sharing
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?
FIG 3.0 will be going to a vote probably towards the end of this month FYI.
So, let's best wait for FIG 3.0 to pass before continuing discussion about this, I think.
@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.