Inheritance diagram for org::xmlBlaster::client::I_Callback:
Public Member Functions | |
| virtual std::string | update (std::string &sessionId, org::xmlBlaster::client::key::UpdateKey &updateKey, unsigned char *content, long contentSize, org::xmlBlaster::client::qos::UpdateQos &updateQos)=0 |
| This is the callback method invoked from CorbaConnection informing the client in an asynchronous mode about a new message. | |
| virtual | ~I_Callback () |
You may use this, if you don't want to program with the rawer CORBA BlasterCallback.update()
Definition at line 24 of file I_Callback.h.
| virtual org::xmlBlaster::client::I_Callback::~I_Callback | ( | ) | [virtual] |
Definition at line 53 of file I_Callback.h.
| virtual std::string org::xmlBlaster::client::I_Callback::update | ( | std::string & | sessionId, | |
| org::xmlBlaster::client::key::UpdateKey & | updateKey, | |||
| unsigned char * | content, | |||
| long | contentSize, | |||
| org::xmlBlaster::client::qos::UpdateQos & | updateQos | |||
| ) | [pure virtual] |
This is the callback method invoked from CorbaConnection informing the client in an asynchronous mode about a new message.
The raw BlasterCallback.update() is unpacked and for each arrived message this update is called.
So you should implement in your client the I_Callback interface - suppling the update() method where you can do with the message whatever you want.
If you do multiple logins with the same I_Callback implementation, the loginName which is delivered with this update() method may be used to dispatch the message to the correct client.
| sessionId | The sessionId to authenticate the callback This sessionId was passed on subscription we can use it to decide if we trust this update() | |
| updateKey | The arrived key | |
| content | The arrived message content. If the size is 0 it is NULL | |
| contentSize | the size of the content of the message | |
| qos | Quality of Service of the org::xmlBlaster::util::MessageUnit |
Implemented in org::xmlBlaster::client::XmlBlasterAccess.