-
Notifications
You must be signed in to change notification settings - Fork 111
Closed
Labels
enhancementNew feature or requestNew feature or requestquestionFurther information is requestedFurther information is requested
Description
This is an issue that has popped up time and time again where sometimes a client doesn't bind properly because the capabilities returned in the wrong shape. This has been because I was following the spec a little to strictly along the V3 line, and ignoring some of the v2 behaviors (Sorry!)
I'm making a fix now that will correct the issue and we'll have the following behaviors.
- If the client supports dynamic registration for a capability
- We will follow that strictly. If dynamic registration is
true
we will not report any static capabilities. This is intended because if we do then we run into issues with binding to the same handlers on the client side twice (once at initialization and once again that dynamic registration).
- If the client does not support dynamic registration, and explicity sets
dynamicRegistration
to false
- We will return the expected static capability
- If the client does not report any capabilities, or support for a particular capability through the capabilities object, we will report our capabilities statically, assuming that if the client supports them it will bind to them. This is the new behavior
PR: #148
Metadata
Metadata
Assignees
Labels
enhancementNew feature or requestNew feature or requestquestionFurther information is requestedFurther information is requested