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

Stateful deserialization of Service::Response #29

Open
rlidwka opened this issue Jun 15, 2024 · 1 comment
Open

Stateful deserialization of Service::Response #29

rlidwka opened this issue Jun 15, 2024 · 1 comment
Labels
enhancement New feature or request question Further information is requested

Comments

@rlidwka
Copy link

rlidwka commented Jun 15, 2024

This PR added stateful deserialization for subscriptions: #20

I'm doing services and actions with dynamic data, such that exact type is not yet known at compile time (it's user-defined in configuration).

Would be very nice to have the same thing for services and actions. I'd like to have Service::async_receive_response_seed function at least to go along with Service::async_receive_response.

Any pointers? If I were to implement it, where should I start?

@jhelovuo jhelovuo added enhancement New feature or request question Further information is requested labels Aug 19, 2024
@jhelovuo
Copy link
Member

This advice is a bit delayed, but here goes.

I'll discuss just Client below. Server is quite accurately a mirror image of Client, so required work is very similar.

A Service Client contains the field response_receiver, which should be modified to allow for seedful deserialization.

The outermost DataWriterR already supports this, but ResponseWrapper does not. It uses deserialize_from_cdr_with_rep_id, which needs to be replaced with the seedful version deserialize_from_cdr_with_decoder_and_rep_id, and the required decoder parameter passed down the stack from the new Service::async_receive_response_seed function.

Implementing this does require studying and understanding the wrappers used to implement various ServiceMappings, which is non-trivial. Otherwise, this basic idea of this generalization should be quite straightforward.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants