Client-Server architecture

[Timoses]

Caster could serve a (for example HTTP) API which could be used by clients to interact with it.

This could solve

• using Caster on a low-power device which would not support running speech recognition; instead a client would send speech recognition requests to Caster server which responds appropriately,
• sending actions to a client on a remote machine
• providing a user interface (e.g. through a browser)
• ...?

[LexiconCode]

Something will have to keep in mind when updating Caster state is watching out threading issues with Natlink. The end result is DNS/DPI freezing recognition temporarily or permanently. How I'd sidestep some of these issues is running every X with a timer.

However I think the architecture will be best served as an caster as a client with a server in between other clients.

• Functions consumed by Grammars would be API, Engine, and OS agnostic
• As fast as possible

We should take care in designing it in such a way that it can be used for other voice coding. That way we get contributions from all across the community enhancing it further. So this could start off here but the architecture could be moved out into dtactions which will support common OS action and related code from dictation-toolbox projects once the repository matures.

[Timoses]

We should take care in designing it in such a way that it can be used for other voice coding. That way we get contributions from all across the community enhancing it further. So this could start off here but the architecture could be moved out into dtactions which will support common OS action and related code from dictation-toolbox projects once the repository matures.

Splitting actions from the speech recognition framework dragonfly sounds like a good idea.

I also think that it's a good idea to try and split stuff up. Caster Core can concentrate on offering features like client/server interactions, event management, etc. while plugins and other libraries offer speech recognition and application specific functionality. So it's important to keep an eye out for how Caster Core implements the plugin and engine/framework interfaces.

Following a client/server model there should be a way to specify where actions should be executed: On the client or the server.

[Timoses]

How about the following:

• The server only handles speech recognitions and replies (or forwards) the results to the clients
• Only clients execute actions

There should be a "standalone" mode which creates a client and server "connected" to each other locally. It would allow a user to just run Caster in the way it is currently known without having to know details about the server/client architecture.

[LexiconCode]

How about the following:

* The server only handles speech recognitions and replies (or forwards) the results to the clients

* Only clients execute actions

There should be a "standalone" mode which creates a client and server "connected" to each other locally. It would allow a user to just run Caster in the way it is currently known without having to know details about the server/client architecture.

I'm in favor of this. Possibly the server is a part of caster core and the GUI and so forth would be client side. While there may be a measure of complexity and the average user doesn't need to be exposed to so many concepts is much as possible to install and run Caster. We should continue to be thinking about that with the documentation as well.

[Timoses]

Possibly the server is a part of caster core and the GUI and so forth would be client side.

Perhaps it would make sense to create a caster-server and caster-client repository/package (later on).

For the beginning it may be worth utilising a simple subpackage/module (e.g. castervoice.server...).

And I agree: The server may provide:

• an API exposed via HTTP
• a web GUI (which essentially could use the HTTP exposed API?)

HTTP exposed API could also be used to create a native GUI client.. However, I'd put my vote in for a web GUI as it's handy and would be accessible from anywhere.