-
Notifications
You must be signed in to change notification settings - Fork 41
RFC: Generic Filters for Subscriptions and FETCH #1164
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
base: main
Are you sure you want to change the base?
Changes from 1 commit
36cedc3
beb7072
455b640
5705af4
bd66412
d5c2340
19e15cd
65a7e24
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
|
|
@@ -1633,6 +1633,58 @@ multi-object stream will expire earlier than Objects later in the stream. Once | |||||
| Objects have expired from cache, their state becomes unknown, and a relay that | ||||||
| handles a downstream request that includes those Objects re-requests them. | ||||||
|
|
||||||
| #### OBJECT FILTER Parameter | ||||||
|
|
||||||
| The OBJECT_FILTER parameter(Parameter Type 0x05) MAY appear in SUBSCRIBE, | ||||||
| SUBSCRIBE_UPDATE, PUBLISH_OK, TRACK_STATUS or FETCH message. It is a structure | ||||||
| indicating Objects or ranges of Objects that the Publisher will deliver. | ||||||
afrind marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||
|
|
||||||
| ~~~ | ||||||
| Object Filter { | ||||||
| Type (0x5), | ||||||
| Length (i), | ||||||
| Operand and Flag (i), | ||||||
|
||||||
| Operand and Flag (i), | |
| Operand and Operator (i), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where Operator can be one !-, =, >, < . I think this will cover a good set of use-cases.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All of those can be express via range filters + negation:
= -> Equal
!= -> Negate + Equal
> -> Range with no end
< -> Negate + Range with no end
It's also unclear what < > mean with multiple ranges.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I realized < X is also trivially implemented as a range from [0,X]
afrind marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
afrind marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
afrind marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
afrind marked this conversation as resolved.
Show resolved
Hide resolved
afrind marked this conversation as resolved.
Show resolved
Hide resolved
afrind marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
afrind marked this conversation as resolved.
Show resolved
Hide resolved
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't want to deal with an unlimited number of filters operations. How about a max of 4 unless someone can come up with a very good use case for more. Keep in mind I would like to be able to implement this on something like a FPGA or silicon for wire speed filtering.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A max seems very sensible.
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I might be reading what you are saying here wrong but ...
If you mean you can send stuff that does not pass the filter, then no, I don't think this should be allowed. I think the stream should be ended if this happens on reliable stream and the things should just be filtered if on datagram.
If you mean that if the filter remove object N but object N+1 is the subgroup passes the filter, you can send N+1 even though N is missing ... then I need to think about what this does to caches downstream.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not saying you should send stuff that doesn't pass the filter. I was thinking the latter. For example f you have a subgroup with objects 0-9, and a filter that says only even objects, then you can put [ 0, 2, 4, 5, 8 ] in a single stream, even though you know you are omitting objects.
That said, I think maybe that is a really bad idea, and we should just use the normal logic and the publisher has to reset the stream and open a new one wherever it skips.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
how about adding this to SubscribeNamespace as well ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's unclear what adding a filter to SUBSCRIBE_NAMESPACE would do without #1047? Or you have different use cases in mind? Let's keep this focused on subscriptions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
adding it to namespace will enable object filtering across the tracks, where the base case is a single subscription . I was suggesting it would be nice to think the filter more generically
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@suhasHere I am amenable to using the same parameter to filter Tracks in response to SUBSCRIBE_NAMESPACE rather than Objects in SUBSCRIBE, but it requires more semantics (for example, most operands defined here don't make any sense). Can you file an issue explaining the requirements for Track filtering first?