[ul] Implement generic Extended Negotiation#734
[ul] Implement generic Extended Negotiation#734pgimeno4d wants to merge 1 commit intoEnet4:masterfrom
Conversation
9cd9c0a to
c9ad719
Compare
|
Rebased on top of #727 so that it can be properly tested with that change applied. |
I guess it is fine for now. I suspect doing more than this would require the inclusion of
That extra type parameter in |
|
Hi @Enet4 and @pgimeno4d: Revisiting this while monitoring status for the other issue #731, which depends on this. Do I understand correctly, that you're waiting to proceed here because this being a breaking change? ... and you don't want to merge this until you're preparing the next version 0.10 which allows breaking changes? What merge policy are you following: do you have a dedicated separate branch for breaking changes? Or do you wait with merging those until you think time has come for breaking changes on master? Considering this, when do you think is a good time to merge this? (I observed, you did one or two releases (which allowed breaking changes) per year in the past... Thank you! |
|
Thank you for your message @stefan-hubert-bl.
The current merging policy would be more of the latter: when there are enough non-breaking contributions to justify a patch release, I merge those and release. There is no fixed timeline, since it has mostly depended on my own availability to work the pull requests. In any case, what I wish to do next is wrap up 0.9.1 by merging #752 and initiating the release process, creating and updating all crates affected. Then the next version will definitely be 0.10.0 and should likely include this PR, so I will do further testing and reviewing at that time to make it happen. |
c9ad719 to
0c5de4e
Compare
|
Rebased, squashed, and some very minor wording changes applied. |
Add a
Negotiationtrait which contains, for the moment, theextended_negotiationmethod. In future it can also help implement Role Selection negotiation (#731) and possibly other currently unimplemented features like Common Extended Negotiation. Note I'm also interested in #731 and will probably submit a patch if this one is merged, as it will depend on said trait.This is a case where the client and the server differ substantially. The
Negotiationtrait is only for the server; the client just adds pairs SOP Class / Byte array. After the association succeeds, they both have the same set of pairs, which they can look up to determine which extended options are active, through the new methodextended_negotiation_for(sop_class_uid: &str)or by walking theuser_variables().Everything is quite low-level, to cover for all current and hopefully future versions of the standard. It's easy to send invalid bytes, for instance.
I'm not quite sure if this is a breaking change. It did not break anything in our application, which is a server. The addition of a new generic concerned me a bit.
Edit: Forgot to mention, this obviously depends on #727, otherwise the bytestream is not correct.