Please report new issues athttps://github.com/DOCGroup
in the TAO_GIOP_Message_Generator_Parser_12 we have a check whether a bidir service context is available, and if so, it is handled. This itself is not nice because bidir is in an optional library and now the core has knowledge about this. I am experimenting with compression and there also data is transmitted through the service context and a solution could be to add also processing in the code, but that also is not a nice solution. It would be better if we have a registry to register service context handlers given an id and an abstract interface. An optional library (bidir, compression but also others) can then register a handler for a given id, the core of TAO then just takes the service context list, searches for each entry if there is a handler registered, if so, do a call to the handler which could then handle that service context (like bidir or compression), if no handler is registered nothing is done. This way also the orb can be independent whether we have bidir or compression and also we could plugin other service context handlers. Probably also something on the sending side could be created to have a handler that creates service contexts, maybe make a difference for the first request and then for all requests.
added Jai, I think he would be interested in such a thing
mine, will have a look at this when implementing compression
did implement a first prototype, going to cleanup that. Idea is to have a registry of service context handlers which can be registered through the orb initializers (or any tao specific initializations). at the moment the giop code encounters a service context list, it defers the handling to the service context registry which looks if there is a sv handler for a certain context, if yes, it is triggered, if not the service context is ignored. that way other libraries (like compression) can register additional service context handlers which are then called when the service context is available. the core then has no knowledge anymore of bidir giop (as it has now)
Fri Mar 7 13:47:30 UTC 2008 Johnny Willemsen <jwillemsen@remedy.nl> * tao/BiDir_GIOP/BiDir_ORBInitializer.cpp: * tao/BiDir_GIOP/BiDir_Service_Context_Handler.cpp: * tao/BiDir_GIOP/BiDir_Service_Context_Handler.h: * tao/BiDir_GIOP/BiDirPolicy_Validator.h: * tao/GIOP_Message_Generator_Parser_12.cpp: * tao/GIOP_Message_Generator_Parser_12.h: * tao/Service_Context_Handler.cpp: * tao/Service_Context_Handler.h: * tao/Service_Context_Handler_Registry.cpp: * tao/Service_Context_Handler_Registry.h: * tao/tao.mpc: Made the handling of service contexts pluggable. Previously the core of TAO did know how to handle the IOP::BI_DIR_IIOP service context. Introduced a new Service Context Handler base class from which concrete handlers are derived, these handlers are then registered with the service context handler registry for a certain context id. This way the BiDIR library handles the BiDIR service context. The future compression support can now also be implemented without that the core knows much about this. The next step is to refactor the adding of the bidir service context to a message in such a way that it is pluggable.
added blocks
bidir, codeset, rtcorba, all have different plugins to add service_contexts. This all seems to be just too much. We need to have a distinction between first request and other requests, and extend the service context handler registry to also support callbacks that add service_contexts
to pool