The APRS-IS specifies a way that clients can filter packets which they receive. This is called server side filtering and is discussed in the Connecting to APRS-IS documentation. The commands themselves are described in Server-side Filter Commands documentation.
APRS# should take advantage of this functionality to filter packets as specified by the user. This should be done through a command line parameter, so it will build on top of the work done in #62.
Although we may want to consider adding fancier shortcuts for these filters later, for now, let's just take a raw filter string as a parameter based on the format defined in Server-side Filter Commands.
Usage should look like this to receive all packets sent by N0CALL: aprssharp --filter b/N0CALL. This should work for any filters which can be constructed on the filter commands page.
Implementation guidance
The good news about server-side filtering is that it's implemented on the server, so this should be relatively straight forward on the client. Accept the string given by the user and pass it straight to the server.
The only difficult part here is validating user input. If the server gives detailed errors on invalid filter strings, reuse that and find a way to show it to the user. Perhaps a new event from AprsIsConnection for warnings/errors rather than packets could be good. If the server does NOT show a warning or error on an invalid filter but instead never returns packets or perhaps ignores the filter and returns all packets, we should work to implement at least a basic check. Perhaps a simple regex match can tell us if the filter is at least close and we can print an error if not.
Acceptance Criteria
[x] Add a parameter to pass a filter string to the APRS-IS server and begin filtering on that string. This should just be accepting a string and passing it through to the server.
[ ] On the help page (e.g. aprssharp --help), include the link to the APRS-IS page on filter commands for reference: http://aprs-is.net/javAPRSFilter.aspx
[ ] Consider a way of validating user input. Try an invalid filter string with a server and see what happens. If the server rejects it, we should find a way to pass that message back to the user and quit. If it doesn't reject it, perhaps we should do a basic check to ensure the command fits a regex or something.
[x] Add tests to ensure the filter is passed to the server appropriately
[ ] Add tests for any validation to ensure all cases in the filter commands document are allowed
Description
The APRS-IS specifies a way that clients can filter packets which they receive. This is called server side filtering and is discussed in the Connecting to APRS-IS documentation. The commands themselves are described in Server-side Filter Commands documentation.
APRS# should take advantage of this functionality to filter packets as specified by the user. This should be done through a command line parameter, so it will build on top of the work done in #62.
Although we may want to consider adding fancier shortcuts for these filters later, for now, let's just take a raw filter string as a parameter based on the format defined in Server-side Filter Commands.
Usage should look like this to receive all packets sent by N0CALL:
aprssharp --filter b/N0CALL. This should work for any filters which can be constructed on the filter commands page.Implementation guidance
The good news about server-side filtering is that it's implemented on the server, so this should be relatively straight forward on the client. Accept the string given by the user and pass it straight to the server.
The only difficult part here is validating user input. If the server gives detailed errors on invalid filter strings, reuse that and find a way to show it to the user. Perhaps a new event from
AprsIsConnectionfor warnings/errors rather than packets could be good. If the server does NOT show a warning or error on an invalid filter but instead never returns packets or perhaps ignores the filter and returns all packets, we should work to implement at least a basic check. Perhaps a simple regex match can tell us if the filter is at least close and we can print an error if not.Acceptance Criteria
aprssharp --help), include the link to the APRS-IS page on filter commands for reference: http://aprs-is.net/javAPRSFilter.aspx