Adding UUIDs to MessageRequests and MessageResponses

[jadahiya-MSFT]

For more information about how to contribute to this repo, visit this page.

Description

Summarize the changes, including the goals and reasons for this change. Be sure to call out any technical or behavior changes that reviewers should be aware of.

If this Pull Request should close/resolve any issues when merged, use the special syntax for that here.

Main changes in the PR:

1. Added in uuid parameter to MessageRequest and MessageResponse objects
2. Modified id to be either a string or number now.

[AE-MS]

Just to let you know my philosophy as I review this:

• The specific message interfaces are fundamentally wire protocol structures (e.g. serialized structures) so I would expect that they would use string to represent UUIDs, since UUIDs would have to be a type that isn't an serialized type (it can be serialized into a string)
• All other uses of UUID throughout the code should use a strongly-typed UUID object to ensure validity and proper usage
• The UUID objects should be created when the messages are deserialized and then turned into a string when serialized into a message.

I haven't started looking at the code yet but this is how I'm thinking about the shape of these changes. Would love to hear more on your thinking about this philosophy and how @TrevorJoelHarris feels about it as well. I don't want to start reviewing until we agree on this because the way I look at the code will vary wildly if our perspectives differ here. #Closed

[jadahiya-MSFT]

Just to let you know my philosophy as I review this:

• The specific message interfaces are fundamentally wire protocol structures (e.g. serialized structures) so I would expect that they would use string to represent UUIDs, since UUIDs would have to be a type that isn't an serialized type (it can be serialized into a string)
• All other uses of UUID throughout the code should use a strongly-typed UUID object to ensure validity and proper usage
• The UUID objects should be created when the messages are deserialized and then turned into a string when serialized into a message.

I haven't started looking at the code yet but this is how I'm thinking about the shape of these changes. Would love to hear more on your thinking about this philosophy and how @TrevorJoelHarris feels about it as well. I don't want to start reviewing until we agree on this because the way I look at the code will vary wildly if our perspectives differ here.

That's an interesting perspective, some of the design considerations were made to not break communication between older versions of the Hosts with newer versions of this SDK and vice versa, newer versions of the Hosts with older versions of this SDK, but I believe that can be reflected in the serialization/deserialization part of the code. I will look into incorporating some of this feedback in the meantime.
#Closed

[AE-MS]

Just to let you know my philosophy as I review this:

• The specific message interfaces are fundamentally wire protocol structures (e.g. serialized structures) so I would expect that they would use string to represent UUIDs, since UUIDs would have to be a type that isn't an serialized type (it can be serialized into a string)
• All other uses of UUID throughout the code should use a strongly-typed UUID object to ensure validity and proper usage
• The UUID objects should be created when the messages are deserialized and then turned into a string when serialized into a message.

I haven't started looking at the code yet but this is how I'm thinking about the shape of these changes. Would love to hear more on your thinking about this philosophy and how @TrevorJoelHarris feels about it as well. I don't want to start reviewing until we agree on this because the way I look at the code will vary wildly if our perspectives differ here.

That's an interesting perspective, some of the design considerations were made to not break communication between older versions of the Hosts with newer versions of this SDK and vice versa, newer versions of the Hosts with older versions of this SDK, but I believe that can be reflected in the serialization/deserialization part of the code. I will look into incorporating some of this feedback in the meantime.

I don't know if having an "interesting" perspective is a good or bad thing? 😅

My desire to use strongly-typed UUID object should only affect the internal implementation within teams-js and not affect back-compat since the serialized message types wouldn't be affected by the internal-to-teamsjs usage. #Closed

[jadahiya-MSFT]

Just to let you know my philosophy as I review this:

• The specific message interfaces are fundamentally wire protocol structures (e.g. serialized structures) so I would expect that they would use string to represent UUIDs, since UUIDs would have to be a type that isn't an serialized type (it can be serialized into a string)
• All other uses of UUID throughout the code should use a strongly-typed UUID object to ensure validity and proper usage
• The UUID objects should be created when the messages are deserialized and then turned into a string when serialized into a message.

I haven't started looking at the code yet but this is how I'm thinking about the shape of these changes. Would love to hear more on your thinking about this philosophy and how @TrevorJoelHarris feels about it as well. I don't want to start reviewing until we agree on this because the way I look at the code will vary wildly if our perspectives differ here.

That's an interesting perspective, some of the design considerations were made to not break communication between older versions of the Hosts with newer versions of this SDK and vice versa, newer versions of the Hosts with older versions of this SDK, but I believe that can be reflected in the serialization/deserialization part of the code. I will look into incorporating some of this feedback in the meantime.

I don't know if having an "interesting" perspective is a good or bad thing? 😅

My desire to use strongly-typed UUID object should only affect the internal implementation within teams-js and not affect back-compat since the serialized message types wouldn't be affected by the internal-to-teamsjs usage.

Poor choice of words on my part. By interesting idea, I meant that I liked it and wanted to look into making the changes to the code to reflect it. 😅 And my second sentence was more to say that using a strongly-typed UUID object wouldn't affect back compat since we can always serialize it to a string or number (for back compat) before putting the message on the wire as you brought up above.
#Closed

[AE-MS]

Just to let you know my philosophy as I review this:

• The specific message interfaces are fundamentally wire protocol structures (e.g. serialized structures) so I would expect that they would use string to represent UUIDs, since UUIDs would have to be a type that isn't an serialized type (it can be serialized into a string)
• All other uses of UUID throughout the code should use a strongly-typed UUID object to ensure validity and proper usage
• The UUID objects should be created when the messages are deserialized and then turned into a string when serialized into a message.

I haven't started looking at the code yet but this is how I'm thinking about the shape of these changes. Would love to hear more on your thinking about this philosophy and how @TrevorJoelHarris feels about it as well. I don't want to start reviewing until we agree on this because the way I look at the code will vary wildly if our perspectives differ here.

That's an interesting perspective, some of the design considerations were made to not break communication between older versions of the Hosts with newer versions of this SDK and vice versa, newer versions of the Hosts with older versions of this SDK, but I believe that can be reflected in the serialization/deserialization part of the code. I will look into incorporating some of this feedback in the meantime.

I don't know if having an "interesting" perspective is a good or bad thing? 😅
My desire to use strongly-typed UUID object should only affect the internal implementation within teams-js and not affect back-compat since the serialized message types wouldn't be affected by the internal-to-teamsjs usage.

Poor choice of words on my part. By interesting idea, I meant that I liked it and wanted to look into making the changes to the code to reflect it. 😅 And my second sentence was more to say that using a strongly-typed UUID object wouldn't affect back compat since we can always serialize it to a string or number (for back compat) before putting the message on the wire as you brought up above.

Sweet and thank you for considering my input and the value of type-safety across our codebase. And won't it be fun to define a custom class to hold a UUID? And then we can start using it elsewhere in the code, too! #Closed

[AE-MS]

[AE-MS]