#include <target_specification.h>
Collaboration diagram for TAO_Target_Specification:
Public Types | |
enum | TAO_Target_Address { Key_Addr = 0, Profile_Addr, Reference_Addr } |
Public Methods | |
TAO_Target_Specification (void) | |
Ctor. More... | |
void | target_specifier (const TAO_ObjectKey &key) |
Set the target specification by giving the object key. More... | |
void | target_specifier (IOP::TaggedProfile &profile) |
Set the target specification by passing in an IOP::TaggedProfile. More... | |
void | target_specifier (IOP::IOR &ior, CORBA::ULong prof_index) |
Specify the target by passing in the IOP::IOR with a profile index. More... | |
const TAO_ObjectKey * | object_key (void) |
Returns the object key after a check of the stored specifier. More... | |
const IOP::TaggedProfile * | profile (void) |
Returns the IOP::TaggedProfile after a check of the stored specifier. More... | |
CORBA::ULong | iop_ior (IOP::IOR *&ior) |
Returns a pointer to IOP::IOR through the parameters and the index of the selected profile as a return parameter after a check of the stored specifier. More... | |
TAO_Target_Address | specifier (void) |
Access the TArget_Address specifier. More... | |
Private Attributes | |
union { | |
TAO_ObjectKey * object_key_ | |
IOP::TaggedProfile * profile_ | |
IOP::IOR * ior_ | |
} | u_ |
TAO_Target_Address | specifier_ |
The enum identifier. More... | |
CORBA::ULong | profile_index_ |
The profile index. More... |
@ Bala: do we have examples of how other protocols map object keys? @ Carlos: The way HTTP-NG does is not quite intuitive. But they too have a sequnce of Octet which more or less fits this model. You are also allowed to specify is a Cache Index (14 bits). I think that can also be worked out and shouldn't be a big deal. @ Bala:What if they pass something around that does not fit this model? @ Carlos:As long as we dont know it is ok. But then if we get to some point where we have something floating around, obviously we would have well defined data structure in TAO. BTW, in IMHO it is not possible for me to think the myriad data structures that a designer can come up with. So, I can look ahead possibily a couple of days but not a life time :-) But you have a good question though. Please sont remove these discussions. It could be useful for someone someday.
|
|
|
Ctor.
|
|
Returns a pointer to IOP::IOR through the parameters and the index of the selected profile as a return parameter after a check of the stored specifier. If the stored specifier is not of the right type then this would return a NULL. |
|
Returns the object key after a check of the stored specifier. If the stored specifier is not of the right type then this would return a NULL |
|
Returns the IOP::TaggedProfile after a check of the stored specifier. If the stored specifier is not of the right type then this would return a NULL |
|
Access the TArget_Address specifier.
|
|
Specify the target by passing in the IOP::IOR with a profile index. Please see the header file IOPC.h on why a profile index is required. |
|
Set the target specification by passing in an IOP::TaggedProfile.
|
|
Set the target specification by giving the object key.
|
|
|
|
|
|
|
|
The profile index.
|
|
The enum identifier.
|
|
|