On Thu, Sep 20, 2012 at 1:44 PM, William Henry <whe...@redhat.com> wrote:
> > > ----- Original Message ----- > > On Thu, Sep 20, 2012 at 12:32 PM, William Henry <whe...@redhat.com> > > wrote: > > > > > > > > > > > ----- Original Message ----- > > > > How about: > > > > > > > > int pn_messenger_subscribe(pn_messenger_t *messenger, const char > > > > *source, > > > > void* context); > > > > > > This one I like. It makes a lot of sense. > > > > > > > void *pn_message_subscribe_context(pn_message_t *msg); > > > > > > > > > > This one less so. I have to make an extra call after I receive the > > > message. Then the implementation needs to do some sort of lookup. > > > I think > > > it would be much more efficient if I had an API that returned the > > > message > > > and the context. > > > > > > > I can't imagine there would be a significant difference in efficiency > > in > > any real world scenario. The internal mechanism to find the context > > should > > be exactly the same either way, and setting the context in an out > > parameter > > vs setting a slot on the message are both just pointer indirection. > > I didn't realize you were setting something in the message. So you would > modify the message? That's ok? > > If it is then I'm good with that. > > My thinking was: you'd have the context when you received the message. > You'd have to look it up the other way. But if you set something when you > receive it then is't more or less the same thing as what I was looking for. > Yeah, the way get works is that it just fills in the message object that you pass it. The idea being that for high performance scenarios you can reuse the same message object, e.g. call get to fill in the new message, process it, and then call get again on that same message object. --Rafael
