Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Received-SPF: pass (athena.apache.org: domain of rohityadav89@gmail.com
 designates 74.125.83.44 as permitted sender)
MIME-Version: 1.0
Sender: rohityadav89@gmail.com
In-Reply-To: <93D78C4D-D0C0-491A-BD02-BB217C38B7E9@basho.com>
References: 
 <C7522783E0E6D3488D82B9A7F7F004B90C478770@SINPEX01CL01.citrite.net>
 <CANLSSBWwGhpj=pLk5RfQn4+-UR6GdqfXWLhyFby995mj0W5UEQ@mail.gmail.com>
 <93D78C4D-D0C0-491A-BD02-BB217C38B7E9@basho.com>
From: Rohit Yadav <bhaisaab@apache.org>
Date: Mon, 8 Apr 2013 23:48:36 +0530
Message-ID: 
 <CANLSSBUyzOY26ZjcaPUp7PTd=wW8gfET+vtNxj8sm+SSAPhefg@mail.gmail.com>
Subject: Re: [Discuss] API name alias
To: dev@cloudstack.apache.org
Content-Type: multipart/alternative; boundary=089e016813d0544e7304d9dd78ff

--089e016813d0544e7304d9dd78ff
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Apr 8, 2013 at 7:10 PM, John Burwell <jburwell@basho.com> wrote:

> Rohit,
>
> Why would we need to rewrite any Java code to switch to an array?  As I
> mentioned, array annotation values are treated as varargs.  Therefore,
> annotations with single values can be left alone.  Only cases where
> multiple values are required would require the addition of curly braces.
>  For example, for an APICommand with one name, the following would continue
> to work:
>

Hey John, you're right but it's a matter of code styling, I prefer writing;

@APICommand(name = {'name1'}) even if it's only one name, this way any
subsequent api author would know that name is an array and they can have
aliases which is what Kishan wants.


>
>         @APICommand(name="apiName1")
>
> While for an APICommand with multiple names, the following form would now
> be supported:
>
>         @APICommand(name={"apiName1", "apiName2", "apiName3"})
>
> I am not familiar with the Marvin code, so I can not speak to the impact
> of this change to it.  However, the only changes to the Java code should be
> the API commands with multiple names and the classes that actually consume
> the value of this annotation.
>

Yes, you're right we can skip the code styling I referred then it won't
consume much coding, we just need to fix these;

- Fix APICommand annotation interface definition to accept name as an array
- Fix method in ApiServer which creates apiname->cmdclass map to care for
aliases
- Fix ApiDiscovery to take care of the aliases (create different response
objs for the same cmd class)
- Fix apidocs XmlWriter class to take of the aliases and the api html
generator to process the same.
- Fix Marvin's codegenerator.py to take care of the aliases (which means
create apiname related modules which would contain cmd and response
boilterplate fields/class)

Cheers.


>
> Thanks,
> -John
>
> On Apr 8, 2013, at 9:22 AM, Rohit Yadav <bhaisaab@apache.org> wrote:
>
> > On Mon, Apr 8, 2013 at 6:33 PM, Kishan Kavala <Kishan.Kavala@citrix.com
> >wrote:
> >
> >> APICommand annotation in API Cmd object has a name parameter. Currently
> >> name parameter takes only one value. I plan to enhance this to support
> >> comma separated values. This will allow multiple API names for the same
> API
> >> Cmd object.
> >>
> >> Current:
> >> @APICommand(name = "apiName1", ..
> >>
> >> Proposed:
> >> @APICommand(name = "apiName1, apiAlias2, apiAlias3", ..
> >>
> >
> > It's a hack, but doable. While not elegant as John suggests, parsing
> comma
> > separated value can lead to some issues.
> >
> > Changing the name field to array would require a lot of rewriting the
> > present apis annotation name fields, again doable by a small python
> program
> > (like the one I used in the last name field refactoring).
> >
> > This would really help remove duplicate cmd classes for apis such as copy
> > iso and volume which does the same job but requires two different cmd
> class
> > implementations.
> >
> > Whatever way you decide, pl. make sure to fix ApiDiscovery, ApiServer
> > cmdclass-apiname map generator method and apidocs generation accordingly.
> >
> > Cheers.
> >
> >
> >>
> >> Requirement:
> >> As part of CLOUDSTACK-763, I'll be introducing NetworkACLList (grouping
> of
> >> NetworkACLItems).  Current APIs use *NetworkACL (create
> >> NetworkACL/deleteNetworkACL etc..) for NetworkACLItem related APIs.
> These
> >> APIs have to be changed to *NetworkACL Item(create
> >> NetworkACLItem/deleteNetworkACLItem etc..) to get the terminology
> right. We
> >> also need to support old API names for backward compatibility. Hence the
> >> need for API name alias.
> >>
> >> Terminology:
> >> NetworkACLItem - Individual ACL Entry (was NetworlACL earlier).
> >> NetworkACL - Group of Network ACL Items. API will use the term
> >> NetworkACLList to differentiate from the existing NetworkACL APIs.
> >>
> >>
> >>
>
>

--089e016813d0544e7304d9dd78ff--