On 02/28/2012 07:30 PM, Andrew Stitcher wrote:
On Tue, 2012-02-28 at 19:08 +0000, Gordon Sim wrote:
On 02/28/2012 06:00 PM, Andrew Stitcher wrote:
I have attached a simplification of this proposal which I believe
encapsulates most of the ways it improves on the original design
Could you elaborate on those improvements?
Functionally it remains similar to the original interface In that the
operations are asynchronous and complete with a callback.
However this proposal is much simpler in detail, in that the proposed
interface is very nearly all the detail you need to specify here.
You mean that in place of an opcode with a description of which data
fields are valid/optional/invalid you have an explicit method call that
lists the valid and optional ones?
I think you could do the same by a discriminated union of different op
structs. I think choosing between those approaches largely comes down to
personal preference, and the difference is not that great.
I myself like a slightly looser interface (any errors in use would be
easily discovered and almost as easily prevented by simple comments in
the interface). It seems to me to be a bit more evolveable (e.g.
hypothetically if you want to start supporting transactional queue
creation/deletion or if you want to add the ability to update a config
entity).
It gets a little more complex if you specify a hierarchy or Handle
classes (which I think is probably a good idea actually)
I agree.
Another simplification is that it uses a single result callback for each
operation - success and failure being distinguished by the type of the
result, and left up to the broker to arrange (probably by having a
virtual method in the AsyncResult class, but this interface does not
need to care).
I agree that having just the one callback might not be to everyone's
taste, but I was consciously trying to pare the interface down to bare
essentials - and I think there is no loss of functionality here.
I'm fairly neutral on one callback with success/failure indication
versus two separate callbacks. (One use case where separate callbacks is
marginally simpler might be where you don't care about successful
completion, but do need to handle failure).
What I do think is important is that the broker can easily get specific
context passed back in some way. I don't see how your design would allow
this but as you note below that may simply be because I don't understand
how you intend the ResultFactory and BrokerContext to be used.
This proposal has all the same async functions as before and I think all
the same Handle classes too, it's just shorter and simpler and I think
pretty much the same to implement as before.
I don't think it is noticeably shorter. Whether it is simpler is I think
again a matter of personal preference.
What would createDataHandle() actually do in general? What about
createFlushHandle()?
(I prefer createMessageHandle() to createEnqueueHandle() - seems more
consistent with the others and more intuitive).
Note I missed passing in the ResultFactory to the StoreAsyncInterface so
it's not clear in the sketch how the store knows how to create those
broker side objects.
How would that work? How do I set up a callback for completion of my
enqueue request for example that allows me to easily determine what
message it refers to and how to handle the completion?
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
