Listen bts: speakerIds- field names spelling on cloud and embeded listeners

####1. Describe Your Issue
I realized that the some APIs are evolving, however I thought it best to report the following.

Using a console.log(speakerIds), I see that the speakerIds object under the cloud and embedded have semantically similar field names, but different spellings.
speaker_idstatus and speaker_ids vs speakerIdStatus and speakerIds
Also the status field uses a two different terminology sources.

cloud helloworld example
Object {speaker_ids: Array[0], speaker_idstatus: “ID-TI-NOT-AVAILABLE”}
speaker_ids: Array[0]speaker_idstatus: "ID-TI-NOT-AVAILABLE"
proto: Object

embedded hey-jibo example
Object {speakerIds: Array[0], speakerIdStatus: “NO-SPEAKERS-TO-LIST”}
speakerIdStatus: "NO-SPEAKERS-TO-LIST"speakerIds: Array[0]
proto: Object

1 Like

Noticed this too and can work around it, but it’s best to be consistent I think with these to make coding for Jibo as easy as possible.

1 Like

I saw it earlier, but figured the API would be updated shortly… then I saw you use it in your template and decided to document it so everyone is aware :wink:

1 Like

Thank you very much for pointing this out! This spelling difference is intentional; in future releases of the SDK, the ASR logs in their raw form will be made invisible to best protect the privacy of Jibo end-users.

I know that the inconsistent spelling between the two objects may be frustrating. We absolutely appreciate everyone’s patience and understanding as we work on evolving the APIs and creating a secure environment for storing end user information.

1 Like

Thanks John for the clarification.
It’s a feature, not a bug - I like that :wink:

1 Like

Thanks @bmulreni! Like you and John said, our APIs are in flux, but it’s super helpful to have devs report things like this. You’ll also be happy to hear that our SDK has reached a much higher level of stability, so you have that to look forward to :smiley: