+1 on Strings
On 29 May 2008, at 05:47, Jim Gomes wrote:
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
