-
Notifications
You must be signed in to change notification settings - Fork 42
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Add message definitions for service events
Signed-off-by: Jacob Perron <[email protected]>
- Loading branch information
1 parent
2a6bf3b
commit 31302a7
Showing
4 changed files
with
39 additions
and
1 deletion.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,20 @@ | ||
# The type of event this message represents | ||
# See ServiceEventType for possible values | ||
uint8 event_type | ||
|
||
# Timestamp for when the event occurred (sent or received time) | ||
builtin_interfaces/Time stamp | ||
|
||
# Unique identifier for the client that sent the service request | ||
# Note, this is only unique for the current session | ||
unique_identifier_msgs/UUID client_id | ||
|
||
# Sequence number for the request | ||
# Combined with the client ID, this creates a unique ID for the service transaction | ||
int64 sequence_number | ||
|
||
string service_name | ||
string request_type_name | ||
string response_type_name | ||
byte[] serialized_request | ||
byte[] serialized_response | ||
This comment has been minimized.
Sorry, something went wrong.
This comment has been minimized.
Sorry, something went wrong. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,14 @@ | ||
# An enumeration of service event types | ||
# These are used to set the type value in ServiceEvent messages | ||
|
||
# A service request was sent by a client | ||
uint8 REQUEST_SENT=0 | ||
|
||
# A service request was recieved by a service | ||
uint8 REQUEST_RECEIVED=1 | ||
|
||
# A service response was sent by a service | ||
uint8 RESPONSE_SENT=2 | ||
|
||
# A service response was received by a client | ||
uint8 RESPONSE_RECEIVED=3 |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
I think it makes more sense to have it as
to save the implementation (and users) from doing two NULL checks to deserialize the content. That is, unless we offer a
deserialize_service_introspection_message
method of some sorts.Unless I'm missing something, separating the request and response types in this message when we're already treating it as a blob that must be serialized/deserialized just seems like extra steps for little benefit; the additional information we get from splitting them up is already captured in
event_type