}
Regards.
From: Nitin Mehta [nitin.me...@citrix.com]
Sent: Friday, December 28, 2012 9:08 AM
To: cloudstack-users@incubator.apache.org
Cc: cloudstack-...@incubator.apache.org
Subject: Re: [VOTE] Enforcing UUID string in API query
Hi Rohit,
I didn't understand the rationale behind this.
lidated.
>>
>> Will
>>
>>> -Original Message-
>>> From: Alex Huang [mailto:alex.hu...@citrix.com]
>>> Sent: Thursday, December 27, 2012 12:44 PM
>>> To: cloudstack-...@incubator.apache.org
>>> Cc: cloudstack-users@incubator.
stack-...@incubator.apache.org
> > Cc: cloudstack-users@incubator.apache.org
> > Subject: RE: [VOTE] Enforcing UUID string in API query
> >
> > Sorry I don't understand why it needs to be a vote. Why can't we just offer
> > a flag to turn it on and off?
> >
-1. At the least we need to depreciate over time, but if at all possible, would
be good to know how many folks are using the existing internal ID.
John
On Dec 27, 2012, at 12:11 PM, Rohit Yadav wrote:
> Hi,
>
> I'm asking for the community to vote if they want to enforce UUID string to
> be
loudstack-users@incubator.apache.org
>> Subject: RE: [VOTE] Enforcing UUID string in API query
>>
>> Sorry I don't understand why it needs to be a vote. Why can't we just offer
>> a flag to turn it on and off?
>>
>> --Alex
>>
>>>
be tested and validated.
Will
> -Original Message-
> From: Alex Huang [mailto:alex.hu...@citrix.com]
> Sent: Thursday, December 27, 2012 12:44 PM
> To: cloudstack-...@incubator.apache.org
> Cc: cloudstack-users@incubator.apache.org
> Subject: RE: [VOTE] Enforcing UUID st
On 27-Dec-2012, at 12:44 PM, Alex Huang wrote:
> Sorry I don't understand why it needs to be a vote. Why can't we just offer
> a flag to turn it on and off?
This needs to be voted because I knew something was not right and the FS kept
emphasising that UUIDs to be accepted.
I knew it would br
-1 - Agree with Will on this.
Matt Mullins
On 12/27/12 3:45 PM, "Will Chan" wrote:
>-1
>
>You will end up breaking anyone that has written any scripts/plugins/apps
>on top of pre 3.x CS. Since UUID was introduced in 3.0, you should only
>accept the following:
>
>- All first class objects
On 12/27/2012 02:11 PM, Rohit Yadav wrote:
Hi,
-1 with a comment: To deprecate an api function, you have two methods
(probably more, but these are common):
1. overload the function to accept both UUID and ID, which gives you
backwards compatibility forever, but is cumbersome to maintain.
2.
Sorry I don't understand why it needs to be a vote. Why can't we just offer a
flag to turn it on and off?
--Alex
> -Original Message-
> From: Rohit Yadav [mailto:rohit.ya...@citrix.com]
> Sent: Thursday, December 27, 2012 12:11 PM
> To: cloudstack-...@incubator.apache.org
> Cc: cloudsta
-1
You will end up breaking anyone that has written any scripts/plugins/apps on
top of pre 3.x CS. Since UUID was introduced in 3.0, you should only accept
the following:
- All first class objects created before 3.0 should accept an normal internal
ID.
- All first class objects created after
Forgot to mention, let's keep the voting period open till 7th Jan 2013 12:00
GMT, i.e. as a lot of people are offline.
On 27-Dec-2012, at 12:11 PM, Rohit Yadav wrote:
> Hi,
>
> I'm asking for the community to vote if they want to enforce UUID string to
> be used in parameters while querying a
12 matches
Mail list logo
