-
Notifications
You must be signed in to change notification settings - Fork 234
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Enable Generator type ProviderState #380
base: master
Are you sure you want to change the base?
Conversation
- Fix semantic commit message. - Remove unused using statements.
I'm not seeing The table there doesn't list |
The spec is a bit of a mess here tbh - only the v4 spec mentions I'm not really sure what to do about that. At the moment we don't support v4 specs, and the v3 spec doesn't mention this. @mefellows do you have any thoughts? I'd rather not add partial generator support for something that's not even mentioned in the spec, and at the same time not implement the things that are mentioned in the spec. That seems backwards :) |
@uglyog is probably best qualified to answer here. I thought the mock server URL and provider state generators were v4 but you're right that the spec docs aren't clear on that. |
The different spec versions really only describe the file formats, not so much the behavior. When generators were added to V3, they were designed to be extensible so that new generators could be added in the future. So while the |
That sounds like a gap in the spec to me though. By mentioning certain generators and not mentioning that it's extensible, it's totally logical to expect that that's a definitive list. There's no way of looking at the V3 spec as it is now and knowing that there could be anything other than the generator types listed, or what to do if you get a type that's not supported (or even how to know if it's supported or not). |
I think this is more of a misunderstanding of what the spec is. The gap is
currently what functional behaviour can be expected across languages.
I would argue the spec should be the definitive place for such things.
…On Mon, 11 Apr 2022, 6:47 pm Adam Rodger, ***@***.***> wrote:
That sounds like a gap in the spec to me though. By mentioning certain
generators and not mentioning that it's extensible, it's totally logical to
expect that that's a definitive list.
There's no way of looking at the V3 spec as it is now and knowing that
there could be anything other than the generator types listed, or what to
do if you get a type that's not supported (or even how to know if it's
supported or not).
—
Reply to this email directly, view it on GitHub
<#380 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAANFDGXII75OBQXNIWZIK3VEPRKJANCNFSM5SCLSGLQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Enable generator type provider state.
Now rust is support provider state injection I have proved it on my client project.
I'll write some usage sample probably inside existing EventAPI.