Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of runseb@gmail.com designates
 209.85.212.173 as permitted sender)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Subject: Re: [DISCUSS] Fwd: jclouds json parsing issue
From: Sebastien Goasguen <runseb@gmail.com>
In-Reply-To: 
 <CANLSSBU6tCn9JD5xBT_MBBVxfOoWvFLWoyc=qWGseXWJE90f9w@mail.gmail.com>
Date: Thu, 31 Jan 2013 09:29:34 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <23A5F519-3FB7-4D1B-93CE-567DDE89584A@gmail.com>
References: 
 <CANLSSBXbEjx+zzauy7S21CC9DZ6LEpfWf=ymxvCuD5AoT-JgTQ@mail.gmail.com>
 <CA+96GG5TbcdGEBxVxJyZQDM2MYv-mqO0eBHyTM3Y7p1tUtGCUA@mail.gmail.com>
 <CANLSSBU6tCn9JD5xBT_MBBVxfOoWvFLWoyc=qWGseXWJE90f9w@mail.gmail.com>
To: cloudstack-dev@incubator.apache.org


On Jan 30, 2013, at 10:17 PM, Rohit Yadav <bhaisaab@apache.org> wrote:

> On Wed, Jan 30, 2013 at 1:06 PM, Chip Childers
> <chip.childers@sungard.com> wrote:
>> On Wed, Jan 30, 2013 at 3:56 PM, Rohit Yadav <rohityadav89@gmail.com> =
wrote:
>>> Did we change the response format to an envelop style?
>>>=20
>>> Cloudstack 3.x
>>> deployvirtualmachineresponse.json : { "deployvirtualmachine" : =
{"id":1234,
>>> "jobid":50006} }
>>> Cloudstack 4.x
>>> new json response : { "deployvirtualmachineresponse" :
>>> =
{"id":"1cce6cb7-2268-47ff-9696-d9e610f6619a","jobid":"13330fc9-8b3e-4582-a=
a3e-90883c041ff0"},
>>> "cloudstack-version": "4.1.0-SNAPSHOT" }
>>=20
>> It looks like there are two changes...  The name of the returned
>> object (deployvirtualmachine vs deployvirtualmachineresponse), as =
well
>> as the addition of the cloudstack-version field.
>=20
> I've no idea about these changes and how and why they were made?
> Comment or advise anyone?
> I've been maintaining and working on the api layer about past two
> months now and I feel this is the layer which the world talks to and
> my aim is to make sure we keep minimal damages to projects who are
> based on top of CloudStack if that requires us to deprecate it and
> adopt something REST-ful or standardized. This is for future of
> course, I still want feedback and info on the changes as Adrian
> mentions.

Rohit,=20

I think we are still trying to figure out if this is a real issue, if =
something got changed or not.
I will see Charles on Friday and we will go through his workflow, I will =
check the version numbers etc and try to figure out what the real issue =
is.

Your work on API refactoring, while I did not follow all of it :), was =
terrific.

Long term there should probably be a move to pure REST.

-Sebastien

>=20
>>=20
>> -chip
>>=20
>>> Forwarding comment from jclouds developer Adrian:
>>>=20
>>> ---------- Forwarded message ----------
>>> From: Adrian Cole <notifications@github.com>
>>> Date: Wed, Jan 30, 2013 at 12:25 PM
>>> Subject: Re: [jclouds] cloudstack renamed =
deployvirtualmachineresponse in
>>> version 4.1 (#1254)
>>> To: jclouds/jclouds <jclouds@noreply.github.com>
>>> Cc: Bhaisaab <rohityadav89@gmail.com>
>>>=20
>>>=20
>>> @bhaisaab <https://github.com/bhaisaab> another note wrt the =
envelope style
>>> used in cloudstack. If you are looking to support multiple version
>>> detection, it would be much easier on us and others to use http =
mechanisms.
>>> typically content mediation is done via headers, rather than =
wrapping
>>> things in a thing that includes version and starts feeling like =
SOAP.
>>> making a generator based on your style of doing versions is =
possible, but
>>> it wouldn't be reusable code. If there's good reason to deviate from =
ReST
>>> and other similar apis wrt Accept header and/or version headers, =
please
>>> consider things that you are doing on your own, as making tools that =
only
>>> work with the cloudstack way isn't enough gain to even use the =
metadata
>>> service you describe. for example, there are specs like HAL
>>> http://stateless.co/hal_specification.html that at least have a =
chance of
>>> tooling support. Alternatively, you could go into the REST community =
and
>>> pitch the way you do things and get others to adopt it. This could =
also
>>> lead to tooling that isn't bespoke only to cloudstack.
>>>=20
>>> =97
>>> Reply to this email directly or view it on
>>> =
GitHub<https://github.com/jclouds/jclouds/issues/1254#issuecomment-1291043=
4>.