qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kim van der Riet <kim.vdr...@redhat.com>
Subject Re: Review Request: Develop Asynchronous Store Interface for Qpid (v.2)
Date Mon, 05 Mar 2012 16:11:55 GMT
This is (hopefully) close to the final thing... I made some small
changes from Gordon's last proposal:

1. Added the DataHandle (Aka MessageHandle) which allows a data source
context so that the store may optimize its storage based on multiple
writes of the same data. This would be most common for messages, but is
also possible for events. I don't see a valid case for queues and
configurations (these being the remaining calls which accept data), but
I kept the paradigm the same for consistency. However, for simplicity,
it might be better to leave these as raw DataSource pointers. Comments?

2. In keeping with Gordon's pattern for handling this pattern, the data
source is now submitted to the createXXXHandle() calls for those that
require them.

3. Also in keeping with Gordon's pattern for EnqueuedMessageHandle
(where the Queue handle is supplied to the handle, not the submitXXX()
call, I have moved all the context handles to the handle factory. This
has the effect of making the submitXX() calls more consistent, taking
only the relevant handle, the callback and broker reference parameters.

4. I removed the raw pointers to handles. I assume we will implement a
Handle-like version of these, so that it is sufficient to pass refs.

If we decide we are getting close, I will cancel the previous
ReviewBoards and create a new one with this proposal; this can then be
used to get a final vote.

Comments welcome.

On Wed, 2012-02-29 at 07:29 +0000, Gordon Sim wrote:
> I don't think you do need store contexts passed back. I think an 
> optional broker provided callback context and a status object (to
> cover 
> both success and failure with the single callback) are sufficient.
> E.g. 
> as attached.

View raw message