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
>

Reply via email to