Developing SpeechDispatcher for .net, final questions

[Rastislav Kish]

Hello list,

so, after a long time, I finally got into writing a Speech Dispatcher
client in pure C# based on the Python speechd.

And while I wasn't particularly eager of the idea on the start, thanks
to the very readable code and thorough foolproof documentation of the
speechd authors, it turned out to be a very straight-forward task.


Thus, after some work, there is finally a full-fledged SpeechDispatcher
client for the latest .net 6, using the most modern language syntax of
the newest C# 10, making the code not just performand but also nice to
read and easy to work with.


The library is practically finished, some functions such as server
autospawning or inet communication are yet to be tested, but the core
functionality seems to work as expected.


There remain just two things, that I'd like to ask before doing some
design choices.


First of all, client name.

I see that speechd requires this as a mandatory argument, SSIP
documentation states, that client name is used for client identification
in logs and a controller application.


I have two subquestions here:

1. Can two clients have the same name and still work as two clients?
I.E. When a programmer sets the parameter to a static value and a user
launches two instances of the app, isn't it going to be interfering? I
might add some suffixing by an unique identifier to prevent this.

2. How likely is any of the SSIP documentation usages for client name
going to happen?

Is it possible to list active spd connections at all? And what are the
possible usecases for viewing SPD logs to find a particular client?

I'm deciding between giving the argument a pregenerated value and
requiring it, like speechd does. The former would be more handy (less
writing, more straightforward in libraries), but then I suppose the
choice in speechd was made for a reason...


My second question is, why does SSIPClient accept connection arguments
in the way it does?

Now it requires a string called address, which seems to be a composition
of communication method and its possible arguments, with values
separated by :.


Is there a specific reason for doing it this way?


 From my perspective it's unnecessarily messy. The SSIP client class is
responsible for parsing the address, the values are on multiple places
added to a dictionary passed around frequently, somewhere it gets
assigned input values, somewhere defaults, somewhere it's checked and
somewhere else it's used.


Not even speaking about strings not being the most reliable input method
for information of this kind. One typo and the speech is broken, without
a prior compiler warning.


I decided for a different strategy. A programmer should be given as
little chance to break things as possible without sacrificing efficiency
or flexibility.

Following the OOP principles, I created an abstract CommunicationMethod
class (record, being more specific), which derivatives represent
connection arguments for unix sockets and inet sockets.

Each of these derivatives handles defaults of the particular
communication method, as well as input arguments validation and
processing (like resolving IP address of a host for inet connection).

Plus, CommunicationMethod class has an abstract CanAutospawn method,
which makes it easy to check whether an inputted communication method
can autospawn a server without checking what method it is and mixing in
the checks themselves.


This way, the result is readable, easy to use, and harder to break from
programmer's point of view.


The last thing I'm considering is, whether to add the string address
variant as well. It shouldn't be a problem from the design side,
CommunicationMethod would get a Parse method, and SSIPClient would offer
a named argument for entering the address in string format.


The question is, whether it would be of any use. Does this notation
appear in, say speechdispatcher configuration, or somewhere else, where
a programmer might want to use it?


Thank you in advance!


Best regards


Rastislav