If we are still on our previously discussed plan (search a wiki shared by
Min) on deprecating the whole query based API (Server), it's just
unnecessary work on present APIs. I think for now just changing the name
attribute type from String to String[] would just work, as John suggested.
Adding other fields, may not hold much use for now. Except for few of them
the rest of 300 apis will have preferred == current apiname and deprecated
as blank string.
I think we should just deprecated all cmd classes (query based) over a long
period say 1 or 2 years, and/or find a way to rewrite/refactor them so as
to reuse them with our new rest based API server for future.
Cheers.
On Tue, Apr 9, 2013 at 3:18 AM, Chiradeep Vittal <
chiradeep.vit...@citrix.com> wrote:
>
>
> On 4/8/13 11:18 AM, "Rohit Yadav" <bhais...@apache.org> wrote:
>
> >On Mon, Apr 8, 2013 at 7:10 PM, John Burwell <jburw...@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 <bhais...@apache.org> wrote:
> >>
> >> > On Mon, Apr 8, 2013 at 6:33 PM, Kishan Kavala
> >><kishan.kav...@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.
> >> >>
>
> How about an additional attribute 'preferred' or 'deprecated' ?
>
> @APICommand(name={'Foo', 'Bar'}, preferred='Foo', deprecated='Bar')
>
>
