Recognizer clients

[alexanderkoller]

Investigate whether the Client classes for speech recognizers can be removed. Currently it seems that the Plugin calls the Recognizer directly, and e.g. PocketSphinxClient is not used anywhere.

[timobaumann]

the Client interface, as I understand it, is orthogonal to use from within the plugin and nodes. One use-case for client interfaces that I see would be to query MaryTTS for how it would speak something (i.e., return MaryXML) from a script node (oder input/output?). But I could be mistaken.

[alexanderkoller]

Oops, I missed this link when I removed the clients.

I don't think clients were meant to be used inside script nodes. But @akoehn , what classes are on the classpath of a Groovy script node? Can they access the *Client classes that I removed for #129? Would there be a way of directly using a method of the Mary plugin to get the same effect?

What's a usecase in which getting the raw MaryXML in a script node would be useful?

[akoehn]

The groovy classpath is the same as the classpath of DialogOS, i.e. it can see everything other classes in DialogOS can see.

Regarding the other classes: I have no idea as I, in fact, have never written an even mildly sophisticated dialogue in DialogOS. I would think that if you want to do something interesting with MaryTTS, you could do that directly instead of going through the client, but I don't remember what the client actually does.

[timobaumann]

wow. that sounds like a bug that we really need to call a feature. Like MacOS9's "cooperative multi-tasking"...

[akoehn]

@timobaumann can you tell me the referent of "that"?

[alexanderkoller]

Presumably the fact that Groovy scripts can access the entire classpath. That is a thing that lives dangerously on the edge between bug and feature. :)

[akoehn]

That is decidedly a feature as we had to manually implement it during the project :-)

I think it's vital to enable rapid prototyping in groovy script. If you are Turing complete, you already have infinitely many possibilities to shoot yourself in the foot, so no harm in adding a few more.

[timobaumann]

I'd love to see reasons to shoot myself in the foot via Groovy. Groovy usage would probably profit greatly from having a few example dialogs (which would also fix @akoehn's issue of never having built a non-trivial dialog model).

[akoehn]

Example one: A speech-based GitHub interface to reply to and close issues.

1. put http://github-api.kohsuke.org/ in classpath
2. use that library via groovy
3. profit

BTW, the script nodes can do all kind of stuff as well, it is just 1) not that well documented and 2) the DialogOS scripting language is a bit inconvenient when working on arbitrary objects.

[akoehn]

@akoehn's issue of never having built a non-trivial dialog model

If you would open that as an issue, I would close it as wontfix :-)