Connection level extensions

[valkum]

Some EPP extensions such as change poll didn't map to the present command oriented extensions. My last PR #60 contained some errors, making it non-working in real life.

Looking at the change poll extension:
The element will be present in the poll response's tag without any elements in the element of the request.
There is, in fact, no allowed value for the element for the poll command (if you only support RGP, NameStore, and ChangePoll). This makes it impossible to encode the ChangePoll response in any call to transact currently.

This now stores enabled general extensions in the EppClient. This allows you to retrieve command level extensions responses using Response::command_extension and connection level extensions using Response::connection_extension.

I am not totally happy with this, as it assumes these might be present for all commands. (Adding the need to use Option downstream). Adding yet another Transaction like trait seems suboptimal, as Transaction already caused some downstream pain, if you remember.

This probably needs some work before it is good enough for a merge.

[valkum]

@djc I am looking forward to some feedback here.

[djc]

Looking at the change poll extension: The element will be present in the poll response's tag without any elements in the element of the request. There is, in fact, no allowed value for the element for the poll command (if you only support RGP, NameStore, and ChangePoll). This makes it impossible to encode the ChangePoll response in any call to transact currently.

This now stores enabled general extensions in the EppClient. This allows you to retrieve command level extensions responses using Response::command_extension and connection level extensions using Response::connection_extension.

Can you explain a bit more the conceptual context here? If it only ever appears in the context of a poll response, could we attach it to this specific command (or this specific response type) instead instead of attaching it to the entire connection?

[djc]

For these impls, it doesn't seem to be an improvement? The Clone and Copy impls are trivial, and the From impl has the bounds right there so it's kind of obvious what's going on?

[djc]

(The generics renaming and making ChangePoll owned changes mostly make sense to me, can merge those as part of a separate PR if you'd like.)

[valkum]

Can you explain a bit more the conceptual context here? If it only ever appears in the context of a poll response, could we attach it to this specific command (or this specific response type) instead instead of attaching it to the entire connection?

Yes. The <changePoll:changeData> element is only present in responses of the command.
But it is not something you enable. The EPP server decides if it will be present or not.
Thus, it makes sense to make this part of the connection or client, or rather session (because there are extensions that you can enable for a session via ext_uris during login). Adding support mapping these session level extensions for different commands as well would be nice, especially if this would be represented in the type system, but I think it would make it overly complex.

I gave this another thought yesterday.
From what I can tell: There will be only a single element in the <resData> part, specified by the different mapping specs.
The extension can contain multiple different elements depending on which extension is enabled.

Having multiple enabled extensions that add elements to <extension> currently requires combinator structs in downstream crates. The easiest would be a struct with fields for all enabled extensions that are optional.
I was thinking of solving this needed complexity by collecting <extension> children into a vec and let downstream code apply any logic needed. Possibly similar to how the http crate stores extensions.
For added safety out of the box, there probably can be a RequestBuilder that also provides a response verifier (using information from the session and the command). This removes some coupling between request and response, but the coupling is already broken for Verisign, as they don't return the Namestore response when RGP is enabled.

But these changes would touch a lot of code in instant-epp. Not sure if you are open for it.

[valkum]

(The generics renaming and making ChangePoll owned changes mostly make sense to me, can merge those as part of a separate PR if you'd like.)

I created #68 but dropped the generics rename commit, as all of them only make sense if a third generic for the client level extensions is added.

[djc]

But these changes would touch a lot of code in instant-epp. Not sure if you are open for it.

I would be open to it if/when I'm paid for the time I spend on it.

I agree a type map like what's used in the http crate could make sense.