Ok, I hadn't realised that settling a delivery in proton-c had such a significant effect on its state.
Does this imply that it's illegal for an application to use a delivery in any way once it's called pn_delivery_settle? If so, we should document this in in the header file. Also, any views on my function name suggestions? Phil On 5 Mar 2013 20:38, "Rafael Schloming" <r...@alum.mit.edu> wrote: > On Tue, Mar 5, 2013 at 11:36 AM, Phil Harvey <p...@philharveyonline.com > >wrote: > > > There's a confusing difference in the meanings of the delivery "is > settled" > > methods in proton-j (Delivery.isSettled) and proton-c > > (pn_delivery_settled): their return values represent the local and remote > > values respectively. proton-j has a separate remotelySettled() method, > > whereas proton-c appears to have no way of accessing the local state. > > > > I'd like to modify one or both apis to resolve this semantic difference. > > There are clearly a number of options. > > > > My favourite is to modify the proton-c function to return the local > value, > > and add a new function to return the remote one. This is consistent with > > the other functions that have local and remote counterparts, eg > > pn_link_source and pn_link_remote_source. If this change in proton-c api > > semantics is too abrupt, maybe we could just deprecate the existing > > function and method and add new ones that are explicit about their > > local/remote meaning. > > > > What do people think? > > > > I don't think it's possible to modify the C API in that way. A locally > settled delivery is actually considered "freed" (really it's returned to a > pool), so it's not possible to actually query that state, i.e. if your > modified pn_delivery_settled(pointer_to_delivery) where to ever return true > then that means you just passed it a pointer to garbage memory. > > --Rafael >