As discussed in #100, a bug was introduced in #98 wherein the default filter input (CLI pushing enter without entering a value) resulted in no packets sent by the server.
This was due to Console.ReadLine() returning an empty string when nothing was entered rather than null as was incorrectly expected.
This change addresses this by moving all "default parameters" logic to the CLI client and out of the server logic. This is consistent with a separation of concerns between the client handling user input and the server library handling server interaction.
This also allows sidestepping the issue of differentiating between a user not supplying a filter (thus wanting the default) or a user supplying explicitly NO filter (not wanting a default or anything else, e.g. the full feed for a server).
This resolves #100.
Changes
Move default parameters logic from the server library to the CLI client
Expose server as a configurable input (helps me during manual testing of changes)
Change the filter parameter logic to not require "filter " at the start, the user can simply specify the rules of the filter
Changed to requiring callsign. "N0CALL" appears to be rejected by servers for connection now anyway. If a user still desires that, they can specify it manually. Password still defaults to the default unverified password of "-1".
Validation
Build and tests pass
Manual validation of both default and provided servers, passwords, and filters and saw packets received. See screenshot below to validate default values (callsign cut out for privacy) returning packets:
Description
As discussed in #100, a bug was introduced in #98 wherein the default filter input (CLI pushing enter without entering a value) resulted in no packets sent by the server.
This was due to
Console.ReadLine()returning an empty string when nothing was entered rather thannullas was incorrectly expected.This change addresses this by moving all "default parameters" logic to the CLI client and out of the server logic. This is consistent with a separation of concerns between the client handling user input and the server library handling server interaction.
This also allows sidestepping the issue of differentiating between a user not supplying a filter (thus wanting the default) or a user supplying explicitly NO filter (not wanting a default or anything else, e.g. the full feed for a server).
This resolves #100.
Changes
Validation