Notifications support #52
No reviewers
Labels
No labels
breaking-change
bug
dependencies
duplicate
enhancement
go
good first issue
help wanted
invalid
investigation
proposal
proposal-accepted
question
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
nemith/netconf!52
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "notifications-support"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
implementation of netconf notifications as per proposal in https://github.com/nemith/netconf/issues/51
I've added a couple of TODOs that we may or may not want to address.
Filter parameter implementation may be out of scope and deserve its own PR, what plans have you for it?
About checks on capabilities I'm not sure you actually want to address them here, at least I don't see other places where you take capabilities into account.
Looks good.
Couple minor nits and it seems like you may need to rebase on top of master (there was some changes with how recv() works.
@ -480,3 +480,46 @@ func (s *Session) CancelCommit(ctx context.Context, opts ...CancelCommitOption)var resp OKRespBeing that this is static i think it's best to just put the namespace into XMLName and not worry about copying it. I fought this same thing with the base netconf namespacing as well.
@ -483,0 +518,4 @@for _, opt := range opts {opt.apply(&req)}// TODO: eventual custom notifications rpc logic, e.g. create subscription only if notification capability is presentI fought this idea too. What should we do if capability is missing, error out? I think it's best left for the future but it is an interesting ida.
The beset practice with mutex locks is to put under them what they are locking. So notificationHandler being here implies it's locked by the mutex lock (and it isn't)
Maybe move it up around the capbilities instead?
notifNamespaceis probably a slightly better name. I was a bit confused when i saynotNamespace@ -176,16 +202,21 @@ func (s *Session) recvMsg() error {return err}This nil check should be done before we decode the notification. This if no handler is present we just drop the message instead of spending time decoding it.
the reader.Close() should advance the reader to the end of the message.
@ -483,0 +518,4 @@for _, opt := range opts {opt.apply(&req)}// TODO: eventual custom notifications rpc logic, e.g. create subscription only if notification capability is presentI agree on leaving it to the future, need some deeper thinking
I rebased and applied fixes as per comments
LGTM to me!
@ -176,16 +202,21 @@ func (s *Session) recvMsg() error {return err}minor nit make this a const block