Hi Mark, I like the idea of having providers extend the session modes to what makes sense for them. For instance, MSMQ may ignore transactional, but have some additional acknowledgment mode. However, what do you propose as a solution such that provider's individual extensions to the acknowledgment mode do not "pollute" the global API space? I like your suggestion of having a loose and flexible API, and I would think that an acknowledgement mode as a string, versus an enumeration, would be the "loosest". But that may not be the best way to go.
Changing to a string might work. The current enumeration could be changed to readonly strings. This way providers would be free to support custom acknowledgment modes through the single parameter. Thoughts? Regards, Jim On Wed, May 28, 2008 at 7:24 PM, Mark Pollack <[EMAIL PROTECTED]> wrote: > Hi, > > > > I'm digging into the NMS API a bit more as I plan to release NMS support in > Spring.NET in the coming months (which James had a hand in as well) and I > have a question regarding the AcknowledgementMode enum. The current values > are those in the JMS spec (DUPS_OK_ACKNOWLEDGE, AUTO_ACKNOWLEDGE, > CLIENT_ACKNOWLEDGE) and an additional one Transactional. > > > > Vendors typically provide additional ack modes for increased performance, > TIBCO EMS is the case I'm familiar with which also has > ExplicitClientAcknowledge, ExplicitClientDupsOkAcknowledge, and > NoAcknowledge. > > > > At the moment the NMS API can't support these modes, making it a > lowest-common denominator solution, something I feel that must be avoided > if > it is to gain widespread use. I've had a similar experience writing a > database wrapper class for ADO.NET and the use of vendor specific enums > for > data types. I ended up leaving the API very 'loose', i.e. method signature > just has 'Enum' in it and internally implementations can check to see if it > makes sense for them. This has worked out well as far as I can tell. > > > > Is it possible to follow the same approach in this case? > > > > Cheers > > Mark > > > >
