Refactor transport

[jerrysxie]

Refactor names in transport to make some the concept more clear, no functional change.

[JamesHuard]

Would like to see the method send() added back

[RobertZ2011]

Overall I think we should also consider a rename of transport to something like message or messaging. I think that better describes the functionality.

[jerrysxie]

Overall I think we should also consider a rename of transport to something like message or messaging. I think that better describes the functionality.

Yeah, I have seen people getting tripped up on this because they see transport as going onto the physical bus, so they think all messages are going onto external bus.

• message::send()
• message::register_endpoint()
• message::MessageDelegate or message::MessageReceiver

@JamesHuard Thoughts?

[JamesHuard]

Overall I think we should also consider a rename of transport to something like message or messaging. I think that better describes the functionality.

Yeah, I have seen people getting tripped up on this because they see transport as going onto the physical bus, so they think all messages are going onto external bus.

• message::send()
• message::register_endpoint()
• message::MessageDelegate or message::MessageReceiver

@JamesHuard Thoughts?

My only concern with calling it "message" is that this might lead people to use it as the primary and only IPC method across the system. The initial intention was to simply offer a layer of agnostic routing between external and internal endpoint protocols, so that subsystems could coalesce these features into a single dispatch unit, and we could avoid duplicate code and ID tracking across various protocol-based services (like HID, FFA, etc.).

Moving towards 'message' as the primary unit of interaction across the system might become difficult to maintain (from a subsystem's perspective) if we have things that aren't protocols going over this communications layer.

Could something like "comms" be sufficient? This might be more intuitive than "transport", as it might imply a more bidirectional relationship between internal and external endpoints, which is where it sounds like the confusion is most manifested.

comms::Message, comms::register_endpoint(), etc.? My gut feeling here is that this would be less likely to encourage the sort of "general message passing" that "message" might incidentally.

[jerrysxie]

Overall I think we should also consider a rename of transport to something like message or messaging. I think that better describes the functionality.

Yeah, I have seen people getting tripped up on this because they see transport as going onto the physical bus, so they think all messages are going onto external bus.

• message::send()
• message::register_endpoint()
• message::MessageDelegate or message::MessageReceiver

@JamesHuard Thoughts?

My only concern with calling it "message" is that this might lead people to use it as the primary and only IPC method across the system. The initial intention was to simply offer a layer of agnostic routing between external and internal endpoint protocols, so that subsystems could coalesce these features into a single dispatch unit, and we could avoid duplicate code and ID tracking across various protocol-based services (like HID, FFA, etc.).

Moving towards 'message' as the primary unit of interaction across the system might become difficult to maintain (from a subsystem's perspective) if we have things that aren't protocols going over this communications layer.

Could something like "comms" be sufficient? This might be more intuitive than "transport", as it might imply a more bidirectional relationship between internal and external endpoints, which is where it sounds like the confusion is most manifested.

comms::Message, comms::register_endpoint(), etc.? My gut feeling here is that this would be less likely to encourage the sort of "general message passing" that "message" might incidentally.

@RobertZ2011 @JamesHuard

• comms::send()
• comms::register_endpoint()
• comms::MessageDelegate or comms::InboxDelegate

Thoughts?

[JamesHuard]

Overall I think we should also consider a rename of transport to something like message or messaging. I think that better describes the functionality.

Yeah, I have seen people getting tripped up on this because they see transport as going onto the physical bus, so they think all messages are going onto external bus.

• message::send()
• message::register_endpoint()
• message::MessageDelegate or message::MessageReceiver

@JamesHuard Thoughts?

My only concern with calling it "message" is that this might lead people to use it as the primary and only IPC method across the system. The initial intention was to simply offer a layer of agnostic routing between external and internal endpoint protocols, so that subsystems could coalesce these features into a single dispatch unit, and we could avoid duplicate code and ID tracking across various protocol-based services (like HID, FFA, etc.).
Moving towards 'message' as the primary unit of interaction across the system might become difficult to maintain (from a subsystem's perspective) if we have things that aren't protocols going over this communications layer.
Could something like "comms" be sufficient? This might be more intuitive than "transport", as it might imply a more bidirectional relationship between internal and external endpoints, which is where it sounds like the confusion is most manifested.
comms::Message, comms::register_endpoint(), etc.? My gut feeling here is that this would be less likely to encourage the sort of "general message passing" that "message" might incidentally.

@RobertZ2011 @JamesHuard

• comms::send()
• comms::register_endpoint()
• comms::MessageDelegate or comms::InboxDelegate

Thoughts?

I like Inbox delegate, it helps enforce the mail-service/mail-box like behavior of the comms service

[RobertZ2011]

I agree with Jimi's concerns over people focusing too much on it as the only IPC method so I think comms works well. I also prefer InboxDelegate for a name. I think changing the method name from process to something like receive would be good as well. Is there anybody who isn't familiar with these APIs that we could loop in? It would be nice to get an opinion from someone who doesn't already have experience with the transport service.

[JamesHuard]

I agree with Jimi's concerns over people focusing too much on it as the only IPC method so I think comms works well. I also prefer InboxDelegate for a name. I think changing the method name from process to something like receive would be good as well. Is there anybody who isn't familiar with these APIs that we could loop in? It would be nice to get an opinion from someone who doesn't already have experience with the transport service.

+1 to receive, that was actually the original name of that function

[jerrysxie]

I agree with Jimi's concerns over people focusing too much on it as the only IPC method so I think comms works well. I also prefer InboxDelegate for a name. I think changing the method name from process to something like receive would be good as well. Is there anybody who isn't familiar with these APIs that we could loop in? It would be nice to get an opinion from someone who doesn't already have experience with the transport service.

@madeleyneVaca and @akshay-rust We rename some constructs in ec-services because people were tripping up by the name and the concepts. Would you guys mind taking a look at https://github.com/pop-project/embedded-services/blob/db0b0c4235721ed66a8a20c430e110119998d0f3/embedded-service/src/comms.rs and its usage in https://github.com/pop-project/embedded-services/blob/db0b0c4235721ed66a8a20c430e110119998d0f3/examples/rt685s-evk/src/bin/mock_espi_service.rs? To check if the new naming scheme makes this service more clear for you guys. Thanks!

[jerrysxie]

@JamesHuard @RobertZ2011 My bad, I clicked on auto-merge. I thought after I reset the approvals, it will not auto-merge, but I guess lesson learned. If there is extra feedback, feel free to comment on this PR. I will make a new PR to address the feedbacks.