speechd-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Developing SpeechDispatcher for .net, final questions


From: Samuel Thibault
Subject: Re: Developing SpeechDispatcher for .net, final questions
Date: Fri, 21 Jan 2022 00:28:50 +0100
User-agent: NeoMutt/20170609 (1.8.3)

Hello,

Rastislav Kish, le lun. 17 janv. 2022 03:12:10 +0000, a ecrit:
> 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.

Yes, that's very convenient for debugging purposes.

> 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?

Interfering, no. But application-specific options do apply.

> I might add some suffixing by an unique identifier to prevent this.

No, you shouldn't. The identifier is meant to identify a particular
application, not an instance of the application. The instances can
already tune their parameters to their liking independently from each
other, while the application-specific configuration is really meant to
be indexed by the identifies the application, not the instance.

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

Whenever somebody takes the time to write it. Personally I don't know
anything but what I can read from the source code and what is already
there in the documentation.

> Is it possible to list active spd connections at all?

Do you mean the documented HISTORY GET CLIENT_LIST?

> And what are the possible usecases for viewing SPD logs to find a
> particular client?

Use cases don't normally include having to look at logs. Logs are only
meant for debugging purposes.

> 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?

I don't know. I hadn't even realized that it was a const
SPDConnectionAddress*, I would have thought it'd be a const char *. I'd
say we want to add a function to the C library that turns a const char*
into a const SPDConnectionAddress*, and all layers above it will only
need to know about a const char*. That way we can trivially extend to
dbus and whatnot without having to update upper layers.

> 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.

Well, an actual typo should really direct the speech to whatever
port/socket is designated. But the function mentioned above could
clearly drop surrounding spaces etc.

> 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?

See spd_get_default_address which just looks at and parses the
SPEECHD_ADDRESS environment variable. Its content would be moved to the
function I mentioned above.

Samuel



reply via email to

[Prev in Thread] Current Thread [Next in Thread]