Request/Response for iceoryx

[elBoberido]

This can be used to coordinate the work on the request/response feature in iceoryx (#27). Lets see if github Discussions are useful for this.

[Indra5196]

Hi @elBoberido,
Instead of using Request / response headers in the port api's, can we directly use Chunkheaders? While allocating chunks using the Client's loan, we can have default template argument of ClientImpl class as the Req header. Similarly with the server class. Are there any implications to this approach?

[elBoberido]

@Indra5196 I'm not quite sure what you mean. The ChunkHeader will be used, but we might need to add additional information which are only relevant to the request/response.

[Indra5196]

You can have a look at client_port_user.cpp. As of now, the ClientPortUser::allocateRequest method is supposed to return the RequestHeader. ChunkSender::tryAllocate() does not return RequestHeader as such. So instead, in the ClientImpl class (which I have to create), I was thinking to use RequestHeader as a default template argument instead of NoUserHeader. Thus, the ClientImpl::loanRequest will directly create a ChunkHeader with RequestHeader as the User Header.

Just wanted to confirm whether this approach wont have any problems : )

[elBoberido]

@Indra5196 I think we do not need a template argument for the RequestHeader since it must always be there. From my understanding, only the payload will be configurable by the user. The user-header will be the RequestHeader/ResponseHeader

[elBoberido]

@Indra5196 I think there are the following tasks we can start the next days

• refactor the current Sample according the design document
  • SmartChunk as base class and Sample, Request and Response as derived classes
• mock for PoshRuntime to ease testing the typed and untyped API
• creating the typed API (Client and Server) with mock ports and write tests with the mock PoshRuntime
• finalize the ClientPort and ServerPort and write test

I would suggest you do the Sample refactoring followed by the typed API. I will create the PoshRuntime mock and take care of the client and server ports.

What do you think?

[elBoberido]

Since we are working from different ends on this, I won't be blocked until I reach the typed API and there is much work in between. So its up to you.

[Indra5196]

Hi @elBoberido

Is the TransmissionInterface just a kind of marker Interface from which the PublisherInterface and RpcInterface would be derived?

[elBoberido]

Yes, kind of. TransmissionInferface is just a template parameter and the Sample will use a PublisherInterface<T, H> for this type.

Edit: To be more clear, it's not a base class from anything and the name could be anything since it's only a template parameter.

[Indra5196]

Hey @elBoberido, Can we keep the SmartChunkPrivateData class inside the SmartChunk as protected? as it will be only used by the SmartChunk class and its childs

[elBoberido]

@Indra5196 I think that's not possible/desireable. The split was done to minimize the amount of duplicated code due to specialization. If it's part of SmartChunk, the whole class needs to be specialized for const T instead of just SmartChunkPrivateData

[Indra5196]

Added this draft PR for sample refactoring #867. Please have a look

[Indra5196]

Hi bob, I have created this new PR which hopefully satisfies all the nomenclature guidelines #871. Sorry for not paying attention to them earlier

[elBoberido]

No problem. It's a formalism one needs to get used to and maybe the first time contributors are not used to.

[elBoberido]

Oh, I just noticed you opened another PR but it seems something is missing compared to #870. Did the rebase -i HEAD~4 not work? Oh, you also need to do a git push -f it that was the problem

[Indra5196]

I did that, but somehow I was able to mess it up real bad. Got a ton of conflicts. So I created a branch out of a fresh fork. Also I am not placing the copyrights as of now, as I need permissions from my seniors for the same

[Indra5196]

Hi @elBoberido, so what should be the next topic for me after ShartChunk ?

[elBoberido]

@Indra5196 the next one would be the typed ClientPort, similar to the typed Publisher and Subscriber. I'll have a look at your PR later today. In general it looks good. Maybe some tests for the new classes need to be added.

[elBoberido]

@Indra5196 what I meant with ClientPort was of course just Client 😀

[Indra5196]

By the way, till when we are targetting to get atleast a beta version of request / response ready?

[elBoberido]

Currently we don't have a target date, except that it will be part of iceoryx 2.0. At the moment I'm also only working part time on it. Is there a target date when you need this feature to be finished? For initial testing and prototyping I could clean up the PoC a bit after your current PR is merged. That will be faster than getting everything into master since we require full tests for all new classes which is the most work. You could also use that PoC to prototype the typed Client and Server API.