Please report new issues athttps://github.com/DOCGroup
with ziop we are using the service context. we do see some limitations, when we send the reply back to the client, we can't check the policies the client has set, there is no way to access them. one idea was to store them in a transport, but for one stub we could have set ziop, for a different one not, storing that data in a transport that is muxed is not an option. with each request the client should send the ziop service context which then must be available in the server as part of the TAO_ServerRequest. An optimization could be that the client doesn't send a service context when the data is compressed, then the server could add an implicit service context to the tao_serverrequest with the compressorid of the received data. Proposal is to pass service context of the TAO_ServerRequest through the sending of the message, so not just the stream, but also the service request.
Isn't the standard way to put the required service context into a slot in request scope context PICurrent ?
not sure if we still have PI at that place in the invocation path. this are orb internal service contexts
I don't think PI will work here. The ZIOP policies are more like the codeset context, the ORB has to transfer them. The ORB core now has a hardcoded hook for codeset, but this should be a Service_Context_Generator, which can be registered into a new registry, the registered objects are then each time called from TAO_Transport::generate_request_header (and probably also from generate_reply_header). The generators can then add service contexts to the request for any policies they are handling.
Also in TAO_RT_Protocols_Hooks::rt_service_context we have code to add service contexts, but then just for rtcorba
mine
RT CORBA service context handling is a hack. In fact, as the comments say, it's a "Mega Hack". It has particular requirements that apparently make it unsuitable for PI - as do CodeSets. That context must be sent on the first use of a transport only - that's not really possible with PI. It sounds like ZIOP is simply a per request service context based on effective policies like the FT service contexts. Why is that not possible to do the proper portable way with PI rather than adding more hacks ?
part can be done in a generic way, but when sending the reply from server to client, after marshaling all data we have to know the effective policy, you FT hint gave me some ideas,
addd 3357
pool