search

async-interop / event-loop

An event loop interface for interoperability in PHP.
MIT License
169 stars 9 forks source link

Async Standards Body #11

Open assertchris opened 8 years ago

assertchris commented 8 years ago

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

davidwdan commented 7 years ago

@TazeTSchnitzel also using an I doesn't address #96

If this group decides to join the FIG, how far out will that push the release of v1?

WyriHaximus commented 7 years ago

Joining or getting the FIG stamp of approval doesn't have to delay v1. Taking the container-interop for example, they're at v1.1 while the PSR is in review and the interop spec is used actively in the wild.

kelunik commented 7 years ago

@WyriHaximus If we plan to join FIG, we should outright name all the things according to their standards.

bwoebi commented 7 years ago

I'd just release our standards with the current naming and then have them decide.

If they don't accept that - that's their problem. There's no need on our side to be part of FIG. If they want async-interop being part of them, they shall accept our naming.

kelunik commented 7 years ago

I think we should setup a small standards body then. I don't think we need many rules, just write down what we already have: Don't merge your own PRs.

WyriHaximus commented 7 years ago

@bwoebi what if the FIG would drop/make the naming standards optional? @michaelcullum what has to be done to make that happen?

bwoebi commented 7 years ago

@kelunik I do not think we need anything more formal than we have currently - just be completely open and listen to anyone having input here.

michaelcullum commented 7 years ago

@WyriHaximus A few specs already ignore it in some instances (6, 3 and 16) so it would just be a simple CC vote you can call. I'm sure they'd rather have you folks in board than not over something which is, let's be honest, trivial.

Also, I think it's worth pointing out that it's not just in the FIG's interest to have async under its umbrella but the wider PHP community and yours as well for reasons previously discussed.

michaelcullum commented 7 years ago

To clarify, the vote is by different people than last time and there is actually reasoning for it (most people voted against it because it was seen as a bike shed point) but a few of those have since said they realise why it wasn't and the point of the cc is to look at the reasons in more depth.

WyriHaximus commented 7 years ago

@WyriHaximus A few specs already ignore it in some instances (6, 3 and 16) so it would just be a simple CC vote you can call. I'm sure they'd rather have you folks in board than not over something which is, let's be honest, trivial.

Interesting, I wasn't aware of that. That should open options for us.

Also, I think it's worth pointing out that it's not just in the FIG's interest to have async under its umbrella but the wider PHP community and yours as well for reasons previously discussed.

Definitely agree, both sides have a lot to offer each other. And I gladly work together to remove any obstacles to make that happen.

mbonneau commented 7 years ago

The people who are interested enough in an async standard are here and can be heard. Why is it necessary to bring outside governance to async-interop? The async-interop members have been doing async for a long time and are the people who actually have a stake in async and know the most about all of the edges associated with it. If FIG, or anyone interested, wants input, they can come here and talk and be listened to.

Especially in these early stages, it makes more sense to spend time refining the standard than dealing with governance issues (imagine if the time spent on this thread was spent on technical issues).

If, in the future, there is a need to "interop" with frameworks, then that would be the time to sync up. At that point differences can be reconciled and a new version can be released. Until then, it is just slowing progress.

Would people be willing to table this discussion until version 1.0 is released?

kelunik commented 7 years ago

imagine if the time spent on this thread was spent on technical issues

@mbonneau I think technical issues are all solved, we just have a few bike shed issues open. #2 is something where we just need a decision, I don't think it's something we can solve through discussion.

WyriHaximus commented 7 years ago

@mbonneau as far as I'm concerned we should get 1.0 out the door first

kelunik commented 7 years ago

@WyriHaximus Yes, I already detached the 1.0.0 milestone here.