Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
Received-SPF: pass (athena.apache.org: domain of e.semog@gmail.com designates
 72.14.220.156 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version
         :content-type:references;
        b=tcQB71WJ6HhYXMik6rwS4SZYtvHWf7tKZ3lCC8gmI8Wq0e4hpaTJIzYyiSzB3c99C3
         7eMNNZbF0NEnINHAJDI9RdlXvDvADj+i30XD3bjWrPu+dOg7PvqtWCMAprOXgImKGj7k
         eZBWk93/8HdVegq+SysI/o4qN4Nt0UX+Ypo/w=
Message-ID: <5a56ce1b0807181333l2d90871dqf97e84bc732942c5@mail.gmail.com>
Date: Fri, 18 Jul 2008 13:33:55 -0700
From: "Jim Gomes" <e.semog@gmail.com>
To: dev@activemq.apache.org
Subject: Re: NMS API design question regarding AckMode
In-Reply-To: <2250661750929900848@unknownmsgid>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_82_30731955.1216413235611"
References: <4008929366804357133@unknownmsgid>
	 <5a56ce1b0805282147s404fd787g8c1b8f47910972e3@mail.gmail.com>
	 <999B4992-40B7-42BA-99D0-AB50FF7E150B@gmail.com>
	 <2250661750929900848@unknownmsgid>

------=_Part_82_30731955.1216413235611
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi Mark,

I have been playing around with this for a while, and here are my findings
for further discussion.

It is possible to change the IConnection interface to use the following
generic types:

    ISession CreateSession(System.Enum acknowledgementMode);
    System.Enum AcknowledgementMode { get; set; }

This would allow for passing in a generic enumeration.  However, I think
that it will force more code to be written using explicit casting in order
to deal with the AcknowledgementMode property in the most general cases.
Since using provider specific acknowledgment modes is the outlyer case, I
think using casting to show specific intent to deviate from standard modes
is preferred.  The C# enum type system is robust enough to support the
following using the existing interface definition without reverting to
generic System.Enum:

    interface IConnection    // SNIPPET
    {
        ISession CreateSession(AcknowledgementMode acknowledgementMode);
        AcknowledgementMode AcknowledgementMode { get; set; }
        }

    enum MyAckModes
    {
        IgnoreDups,
        Transactional,
        Explicit
    }

    IConnection connection = GetConnection();
    // Set the default ack mode
    connection.AcknowledgementMode = (AcknowledgementMode)
MyAckModes.IgnoreDups;
    // Set session-specific ack mode
    ISession session = connection.CreateSession((AcknowledgementMode)
MyAckModes.Explicit);

As can be seen from this snippet of code, the existing code base allows the
use of provider specific enumerations while providing type-safety and
non-casting for the general case.  When a user of NMS wants to have
low-level access to a provider's unique acknowledgment modes, then they can
do so and the C# enum system will carry their values through, even if that
acknowledgment mode value is outside the range of the original
AcknowledgmentMode enumeration.  I have created a sample C# app that
demonstrates basic casting of enumerations to show that provider specific
enumeration values can be "carried" inside the existing AcknowledgementMode
enumeration.  Since these values only make sense to the individual
providers, they will be the ones who will cast when setting/getting the
AcknowledgementMode property.

using System;

public class EnumTest
{
    enum MyEnum        { First, Second, Third }
    enum ProviderEnum  { Fourth, Fifth }

    static void ShowEnum(System.Enum baseEnum)
    {
        Console.WriteLine("base = {0}", baseEnum);
        ProviderEnum derived = (ProviderEnum) baseEnum;
        Console.WriteLine("derived = {0}", derived);
    }

    static void Main()
    {
        ShowEnum(MyEnum.Second);
        ShowEnum(MyEnum.Third);
    }
}

I hope that this addresses the concerns about using provider specific
extensions to the acknowledgment mode enumeration.  Let me know if I didn't
explain anything clearly.   I am interested in your comments on this
proposal.

- Jim

On Mon, Jun 9, 2008 at 12:27 PM, Mark Pollack <mark.pollack@springsource.com>
wrote:

> Hi,
>
> Just a ping to see if we can get closure on an approach...
>
> Mark
>
>
> -----Original Message-----
> From: Mark Pollack [mailto:mark.pollack@springsource.com]
> Sent: Thursday, May 29, 2008 10:09 AM
> To: 'dev@activemq.apache.org'
> Subject: RE: NMS API design question regarding AckMode
>
> Hi,
>
> My suggestion is to have the base enumeration class, System.Enum, be used.
> I suspect that all .NET messaging providers have used enums for ack modes
> and if they didn't, the NMS implementation for that provider could supply
> one.
>
> In the case of the EMS binding, this would read
>
> connection.CreateSession(SessionMode.NoAcknowledge)
>
> This seems more natural than using a literal string.  All the general
> arguments of enum vs. string apply here.
>
> I used this approach with System.Data.DbType, the base enum for data types
> in ADO.NET.  All ADO.NET providers have their own custom enum (for
> 'advanced' data types like xml, arrays etc.)  This has seemed to work out
> well, at least no complaints.
>
> Cheers,
> Mark
>
>
>
>
>
>
>
>
>
>
> -----Original Message-----
> From: Rob Davies [mailto:rajdavies@gmail.com]
> Sent: Thursday, May 29, 2008 2:32 AM
> To: dev@activemq.apache.org
> Subject: Re: NMS API design question regarding AckMode
>
> +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
> <mark.pollack@springsource.com
> > >
> > 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
> >>
> >>
> >>
> >>
>
>
>

------=_Part_82_30731955.1216413235611--