On Tue, 2012-02-28 at 20:24 +0000, Gordon Sim wrote: > ... > > 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.
The intent is that BrokerContext is a base class which encapsulates whatever context the broker wantsd to associate with a handle so that it can simply use that BrokerContext to figure out exactly what the result relates to. The point of the ResultFactory is simply that the broker side must have control of creating and destroying the Results since they end up on the broker side. > > > 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. Well, it is noticeably simpler than either of Kim's proposals because I've dropped all the class definitions that aren't necessary for the specific interface being defined - that certainly makes it easier for me to read - it doesn't make the actual usage very much different I agree. > > What would createDataHandle() actually do in general? What about > createFlushHandle()? The most important point of the Handle factories is to associate the BrokerContext with a Handle so that the broker knows what the handle refers to. > > (I prefer createMessageHandle() to createEnqueueHandle() - seems more > consistent with the others and more intuitive). Actually I simply replaced "next" in the v2 proposal with "create" - I meant nothing semantic here. Although I'd note that Messages and Enqueues are in fact separate things, especially if we want to avoid copying the same message to multiple on disk queues some day. In the context of this v2 proposal I think that the DataHandle actually is closer to the idea of Message. > > > 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? You know because the Result contains a Handle from which you can extract the BrokerContext which presumably has a not which message was enqueued in that request. Andrew --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
