Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Voice] Allow hli list #2906

Merged
merged 9 commits into from
May 11, 2022
Merged

[Voice] Allow hli list #2906

merged 9 commits into from
May 11, 2022

Conversation

GiviMAD
Copy link
Member

@GiviMAD GiviMAD commented Apr 10, 2022

Signed-off-by: Miguel Álvarez Díez miguelwork92@gmail.com

This is a proposed solution for #2904 based on the feedback from @lolodomo.

Basically allows to pass a comma separate list of hli ids instead of a single one.

I have some doubts about renaming the hli vars, and the 'getHLI' methods, as there is already a getHLIs method that returns all the available interpreters, let me know if it's better to rename them.

@GiviMAD GiviMAD requested a review from a team as a code owner April 10, 2022 09:51
@GiviMAD GiviMAD changed the title [Voice] Allow hli list [WIP][Voice] Allow hli list Apr 10, 2022
@GiviMAD
Copy link
Member Author

GiviMAD commented Apr 10, 2022

ups, adding WIP

@lolodomo
Copy link
Contributor

You should keep getHLI unchanged and add a new method taking a comma separated list of IDs and returning a list of HLI. .

Note the typo: comma separated list

@GiviMAD
Copy link
Member Author

GiviMAD commented Apr 10, 2022

You should keep getHLI unchanged and add a new method taking a comma separated list of IDs and returning a list of HLI

Ok, but there will be no uses for the 'getHLI(String id)' method other than inside the own VoiceManager, as all the places will call the new method 'getHLIByIds(String idList)'. Is this ok?

Edit: Done. I have added 2 new methods at the end because another one was needed to replace the 'getHLI()' method call in some places.

@lolodomo
Copy link
Contributor

I think it is better, it avoids breaking the interface and it avoids having a method name not matching what it does.

@GiviMAD
Copy link
Member Author

GiviMAD commented Apr 10, 2022

I think it is better, it avoids breaking the interface and it avoids having a method name not matching what it does.

Yes it makes sense, specially the last part, thanks for the explanation.

@GiviMAD
Copy link
Member Author

GiviMAD commented Apr 10, 2022

I forgot to apply spotless last time.

@GiviMAD
Copy link
Member Author

GiviMAD commented Apr 10, 2022

Now is ready for review.

@GiviMAD GiviMAD changed the title [WIP][Voice] Allow hli list [Voice] Allow hli list Apr 10, 2022
@GiviMAD
Copy link
Member Author

GiviMAD commented Apr 17, 2022

@lolodomo I have solve part of the review.
Can you explain me the reason why you think is better to support just one default interpreter while allowing to use multiples? For me it breaks a little the default functionality as if you want to always use multiple interpreters (this is my case) you can not rely on the default value anymore.

@wborn wborn added the enhancement An enhancement or new feature of the Core label Apr 22, 2022
@GiviMAD
Copy link
Member Author

GiviMAD commented Apr 26, 2022

@lolodomo I have finally followed your advice so I can complete the review.
I'll open an issue on the future to discuss there if it is a good idea to support multiple interpreters as default or not.

@GiviMAD GiviMAD force-pushed the voice/hli_chain branch 2 times, most recently from 48cc12f to 848eea0 Compare April 26, 2022 15:39
Signed-off-by: Miguel Álvarez Díez <miguelwork92@gmail.com>
@GiviMAD GiviMAD requested a review from lolodomo April 26, 2022 18:36
Copy link
Contributor

@lolodomo lolodomo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Still few comments.

@lolodomo
Copy link
Contributor

@GiviMAD : most of my remaining comments are about documentation, I think there is not too much work to finish.

Copy link
Member

@J-N-K J-N-K left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for being late to the party. I have one general question (which is probably due to me missing knowledge on this part, I never used HLI): If there are multiple HLI and they are all listed, the first result is taken. Could it happen that the user is interested in the result of another HLI? Since Collection in general does not guarantee order, the user can't control which HLI is queried first.

@lolodomo
Copy link
Contributor

lolodomo commented Apr 27, 2022

If there are multiple HLI and they are all listed, the first result is taken. Could it happen that the user is interested in the result of another HLI? Since Collection in general does not guarantee order, the user can't control which HLI is queried first.

The order was very important. The user just wants to get the result of the first interpreter able to interpret, considering an ordered list of interpreters.
So Collection was a bad choice. I have this question in mind and finally totally forgot it !

@lolodomo
Copy link
Contributor

lolodomo commented Apr 27, 2022

Considering @J-N-K comments, I think we should duplicate REST API and actions for "interpret", keeping the existing ones unchanged. That means, we forget the idea of a string containing a coma separated list of ids.

For "startDialog" and "listenAndAnswer", as this is recent features added, we can directly consider the list of interpreters as parameter without duplicating them.

For REST API, having a List as parameter is not a problem.
But for actions, will it be possible to pass a list of strings as parameter in a rule ? What would be the syntax in a DSL rule for example ?

And finally, is List the right class for an ordered list ?

Signed-off-by: Miguel Álvarez Díez <miguelwork92@gmail.com>
@GiviMAD GiviMAD requested a review from J-N-K April 27, 2022 16:21
Copy link
Member

@J-N-K J-N-K left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Signed-off-by: Miguel Álvarez Díez <miguelwork92@gmail.com>
Signed-off-by: Miguel Álvarez Díez <miguelwork92@gmail.com>
@GiviMAD GiviMAD force-pushed the voice/hli_chain branch from 0b08c2c to 60fd793 Compare May 5, 2022 19:40
@GiviMAD GiviMAD requested a review from J-N-K May 5, 2022 19:41
Copy link
Contributor

@lolodomo lolodomo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Final review

Signed-off-by: Miguel Álvarez Díez <miguelwork92@gmail.com>
Copy link
Contributor

@lolodomo lolodomo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thank you @GiviMAD
The parameters for REST API that have been marked as deprecated could be discussed as these REST API were added very recently and are only available in 3.3 snapshots and 3.3 milestones.

@lolodomo
Copy link
Contributor

@GiviMAD ; is it clear for you what must be kept as deprecated and what must be removed?

@GiviMAD
Copy link
Member Author

GiviMAD commented May 10, 2022

@GiviMAD ; is it clear for you what must be kept as deprecated and what must be removed?

@lolodomo I think so, I'll go for it.

Signed-off-by: Miguel Álvarez Díez <miguelwork92@gmail.com>
@GiviMAD GiviMAD requested a review from lolodomo May 10, 2022 19:38
@lolodomo
Copy link
Contributor

Perfect IMHO

@lolodomo
Copy link
Contributor

Once merged, I will propose a big update in the documentation to add/update all existing actions and console commands about voice management.

Copy link
Member

@J-N-K J-N-K left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks.

@J-N-K J-N-K merged commit 5753627 into openhab:main May 11, 2022
wborn added a commit to wborn/openhab-core that referenced this pull request May 23, 2022
This fixes the null type errors in Eclipse which were introduced by openhab#2906.

Signed-off-by: Wouter Born <github@maindrain.net>
J-N-K pushed a commit that referenced this pull request May 23, 2022
This fixes the null type errors in Eclipse which were introduced by #2906.

Signed-off-by: Wouter Born <github@maindrain.net>
@wborn wborn added this to the 3.3 milestone Jun 23, 2022
splatch pushed a commit to ConnectorIO/copybara-hab-core that referenced this pull request Jul 12, 2023
* [Voice] Allow hli list

Signed-off-by: Miguel Álvarez Díez <miguelwork92@gmail.com>
GitOrigin-RevId: 5753627
splatch pushed a commit to ConnectorIO/copybara-hab-core that referenced this pull request Jul 12, 2023
This fixes the null type errors in Eclipse which were introduced by openhab#2906.

Signed-off-by: Wouter Born <github@maindrain.net>
GitOrigin-RevId: 86ee4dc
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement An enhancement or new feature of the Core
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants