Avis transport and msg bridges not decoupled to allow use of one without the other

David @ Rai Technology

Hi Guys,
I have been looking that example payload and bridge code and doing some test coding around building a different bridge. Initially I was thinking of just doing the bridge and using the Avis msg payload, however I think the Avis payload and transport bridges are a little tightly coupled to allow one to be used without the other. this may be inadvertent or done for optimisation reasons but given it is the only example is not so good.

I am assuming that a transport bridge should be able to function without any hard coded information about the payload format being used, so in the code fragment below the passed in mamaMsg could be one of a nunber of payload implementations. The call mamaMsgImpl_getPayloadBuffer() should return a packed message buffer ready for passing to the transport for sending.

The Avis transport bridge makes the assumption that it will receive an Attribute object, tweaks with this object then passes it to the sending routine. I can see why it is more efficient for the getPayloadBuffer to return the Attribute object rather than a flattened buffer as the later elvin_send call takes and Attribute object as a parameter so to avoid serialising and un-serialising again the assumption is made that a pointer to the Attribute object will be passed.

Digging upstream inside the getPayloadBuffer() call it is resolved to the avis payload bridge function avismsgPayload_getByteBuffer(). In this function a pointer to the Attributes is returned instead of the Attributes being serialised with avismsgPayload_serialize(). I understand that is not optimal to serialize, then have to unserialize again only to have the message serialized again in the send but I'm thinking that ba more flexible solution would be to do it properly and create a patch to Avis to add a send method for a pre-serialised buffer.

Interested if anyone else has come across this and if any sees it as a problem.

snip ----bridge/avis/publish.c ----x

 146 /*Send a message.*/
 147 mama_status
 148 avisBridgeMamaPublisher_send (publisherBridge publisher, mamaMsg msg)
 149 {
 150     mama_size_t        dataLen;
 151     mama_status        status
 152     Attributes* attributes = NULL;
 154     CHECK_PUBLISHER(publisher);
 156     status = mamaMsgImpl_getPayloadBuffer (msg, (const void**)&attributes, &dataLen);
 157     if (attributes == NULL)
 158         return MAMA_STATUS_INVALID_ARG;
 160     mamaMsg_updateString(msg, SUBJECT_FIELD_NAME, 0, avisPublisher(publisher)->mSubject);
 162     if (!elvin_send(avisPublisher(publisher)->mAvis, attributes)) {
 163         mama_log (MAMA_LOG_LEVEL_ERROR, "avisBridgeMamaPublisher_send(): "
 164                   "Could not send message.");
 165         return MAMA_STATUS_PLATFORM;
 166     }

Join Openmama-dev@lists.openmama.org to automatically receive all group messages.