Default filter does not work in APRSSharp CLI
CBielstein opened this issue · comments
Description
The APRS# CLI client has always supported a default filter so that packets can be received even if a user doesn't know how to craft a filter.
Unfortunately, it seems that #98 broke that default filter. Based on initial debugging, this appears to be because the result of Console.ReadLine()
is never null, but simply an empty string. Since the default filter is only applied if the user-supplied filter string is null, the default never kicks in.
We need to resolve this issue in a way that allows AprsIsConnection
to accept the option to not filter messages (e.g. programming a server) without exposing that to AprsSharp
CLI.
This should likely be fixed with the following steps:
- Update
AprsIsConnection.Receive
to have a default value for thefilter
parameter. Use that default value as the default filter. - Update
AprsIsConnection.Receive
to only apply the filter string if thefilter
parameter is not null. Thus allowing receiving without a filter. - Update the
AprsSharp
CLI client to only pass the user-supplied filter argument if it's not empty.
Acceptance Criteria
-
AprsSharp
can again receive packets when no filter is supplied by the user -
AprsIsConnection
can connect without a filter (don't have to test this...it's considered bad practice to received unfiltered from a normal T2 server) -
AprsSharp
cannot specify a "no filter" scenario
Picking up this issue quickly to not leave the CLI broken. I'm going with the approach of moving defaults to the CLI app. AprsIsConnection
clients will be more advanced in general, so the defaults aren't needed there. Indeed, it now appears that most servers are rejecting "N0CALL"
as a login anyway.