qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ken Giusti <kgiu...@redhat.com>
Subject Re: proton application context API deprecated in 0.9?
Date Mon, 09 Mar 2015 20:11:51 GMT
Hi Rafi - thank you for that description.  I'll have to dig into that code a bit more to get
a feel for it.

The only concern I have is the implementation of PN_HANDLE.  If I'm correct, you can't directly
share PN_HANDLE's across compilation units due to the use of static variables. In other words,
if I have

PN_HANDLE(RAFI);

in my rafi_private.h header, each compilation unit will define a RAFI handle with a different
underlying value.

Since it's not a compilation-time error, this could result in a very hard to diagnose run
time bug.

Perhaps a simple #defined constant would be safer?

----- Original Message -----
> From: "Rafael Schloming" <rhs@alum.mit.edu>
> To: users@qpid.apache.org
> Sent: Monday, March 9, 2015 3:10:47 PM
> Subject: Re: proton application context API deprecated in 0.9?
> 
> On Mon, Mar 9, 2015 at 10:35 AM, Ken Giusti <kgiusti@redhat.com> wrote:
> 
> > Hi,
> >
> > I just noticed that the 0.9rc1 marks the
> > pn_XXX_get_context()/pn_XXX_set_context() set of APIs as being deprecated.
> >
> > I use these apis fairly frequently as a means to map back to my
> > application's context.
> >
> > What are they being replaced with?   I couldn't find an associated JIRA
> > explaining how to upgrade my code.
> >
> > thanks,
> >
> 
> The context API has been replaced with the attachments API. The attachments
> API provides two key improvements over contexts. Firstly, you can have
> multiple attachments for a given object without them interfering with each
> other. Secondly, it permits you to define the type of each attachment,
> thereby allowing simpler options for memory management since you can use
> reference counted pointers if you wish.
> 
> The general pattern is:
> 
>     PN_HANDLE(FOO) // this is a macro that defines FOO to refer to a static
> memory location guaranteed to be unique within the program
> 
>     pn_record_t *record = pn_xxx_attachments(xxx);
>     pn_record_def(record, FOO, PN_VOID | PN_OBJECT);
>     pn_record_set(record, FOO, value);
>     void *value = pn_record_get(record, FOO);
> 
> For real use you'll probably want to wrap the get/set with accessors that
> cast foo to/from a more specific type, e.g.:
> 
>     pn_foo_t *pn_xxx_get_foo(xxx);
>     void pn_xxx_set_foo(xxx, pn_foo_t *foo);
> 
> I just noticed the pn_record_t API is missing doxygen. I'll add it to the
> list for a doc blitz. I have a plane ride coming up soon, so hopefully will
> have some time to churn out the missing doc pieces here.
> 
> --Rafael
> 

-- 
-K

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org


Mime
View raw message