Re: [Openstack] Image API v2 Draft 4
On Fri, Apr 13, 2012 at 1:28 AM, Jorge Williams jorge.willi...@rackspace.com wrote: Having said all of that, I realize that our devs are working in a dynamic language, and don't see a lot of value in XML. It's important to take that into consideration, but we should also be asking whether there's value to our current clients and potential clients. Like it or not, there's a lot of folks out there using static languages. I actually think this is an important point (But in favor of JSON!). The OpenStack developers are writing in a dynamic language, python. This means the tooling and experience available will be biased towards JSON over XML for the most part. This, IMHO, will result in a less than perfect XML implementation. I would much prefer to see a single great XML or JSON implementation rather than two poor implementations. Combine that with the massive uptake of dynamic languages over recent years, and I would bet JSON is a more natural fit for a higher percent of developers and end users (Please notice I said I would bet, not I know). Maybe RackSpace (or any other large operator..) can share some stats of the user-agents they see in the wild? Thanks, Kiall (A, likely biased, dynamic language guy ;)) ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Image API v2 Draft 4
A little fuel for the fire / entertainment before the summit: http://www.mnot.net/blog/2012/04/13/json_or_xml_just_decide Cheers, On 10/04/2012, at 3:56 PM, Vishvananda Ishaya wrote: On Apr 10, 2012, at 2:26 AM, Thierry Carrez wrote: Jay Pipes wrote: I take it you didn't attend the glorious JSON debate of a couple of summits ago :-) Glorious it was indeed. I think the key quote was something like: Please don't bastardize my JSON with your XML crap According to my twitter, the actual quote was: Don't bring your XML filth into my JSON Vish ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Mark Nottingham http://www.mnot.net/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Image API v2 Draft 4
I may disagree with a couple of the points along the way; but I agree with the conclusion for OpenStack. Thanks for writing it! Justin PS vim or emacs? On Thu, Apr 12, 2012 at 12:58 PM, Mark Nottingham m...@mnot.net wrote: A little fuel for the fire / entertainment before the summit: http://www.mnot.net/blog/2012/04/13/json_or_xml_just_decide Cheers, On 10/04/2012, at 3:56 PM, Vishvananda Ishaya wrote: On Apr 10, 2012, at 2:26 AM, Thierry Carrez wrote: Jay Pipes wrote: I take it you didn't attend the glorious JSON debate of a couple of summits ago :-) Glorious it was indeed. I think the key quote was something like: Please don't bastardize my JSON with your XML crap According to my twitter, the actual quote was: Don't bring your XML filth into my JSON Vish ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Mark Nottingham http://www.mnot.net/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Image API v2 Draft 4
On 04/12/2012 03:58 PM, Mark Nottingham wrote: A little fuel for the fire / entertainment before the summit: http://www.mnot.net/blog/2012/04/13/json_or_xml_just_decide I *have* to point out that your article is published on Friday the 13th. Just sayin' :) -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Image API v2 Draft 4
Generally, I agree with a lot of what you're saying, but I want to point out a couple of things: 1. Static language folks gravitate to XML, not simply because they're invested in it, but because it solves a real problem: In a static language, I want to to say something like: myServer.name = hello; if I misspell name myServer.nam = hello; I should see an error...if I assign it to an integer... myServer.name=10; I should also see an error... and I should see those errors at compile time or while I'm authoring my code if a have a good editor or IDEI shouldn't have to wait until my program is run to catch those errors. Sure, I can parse some JSON turn the result into a hashtable and if I'm using something like Scala, I can do this myServer(name) = hello but at that point, there's very little benefit to having a static language, because I don't have the assurances and guarantees that the language provides. So I don't see a lot of Java folks dealing with JSON in that manner. Most devs will need to build a class before hand. So, you decrease barriers for static language clients because there's a set of tools that can extract the relevant info from XML schema languages and generate a set of class files at compile time. There's nothing saying you can't do something similar with JSON, but those sort of tools aren't there yet. 2. Then there's the issue of extensibilityespecially distributed extensibility. XML has that notion built in, JSON has no concept of it...and we are building extensible APIs. There are no standard way in JSON to introduce a new property without guaranteeing that there won't be clash. You've mention the need for namespaces in JSON precisely to deal with this sort of issue (http://www.mnot.net/blog/2011/10/12/thinking_about_namespaces_in_json). In the absence of a standard method, we're been using prefixes, which has worked out well, but most JSON tools don't know how to deal with them and they seem alien to folk that are used to using JSON day to day. This is a big deal because dynamic language folks are more likely to deal with the JSON directly...Static language folks are generally not dealing with XML in the same way. In XML, the notion of extensibility is build into parsers and data binding tools directly. Most folks don't have to worry too much about it. In fact extensible protocols like XMPP and Atom Pub generally benefit from the extensibility that's already built in: http://metajack.im/2010/02/01/json-versus-xml-not-as-simple-as-you-think/ Given that, if we're going to go the route of just picking one format, I think the fact that our API is extensible means that we might want to ask ourselves whether XML isn't a better fit :-) Having said all of that, I realize that our devs are working in a dynamic language, and don't see a lot of value in XML. It's important to take that into consideration, but we should also be asking whether there's value to our current clients and potential clients. Like it or not, there's a lot of folks out there using static languages. You're right in stating that if we had really good language bindings for Java and .Net, then issue #1 would essentially go away -- especially if we had language binding that was flexible enough to remove the need to go down to the HTTP level. Also, if the language binding itself was extensible we could also deal with issue 2. As things stand today though, I don't thing that we are even remotely there yet. -jOrGe W. On Apr 12, 2012, at 2:58 PM, Mark Nottingham wrote: A little fuel for the fire / entertainment before the summit: http://www.mnot.net/blog/2012/04/13/json_or_xml_just_decide Cheers, On 10/04/2012, at 3:56 PM, Vishvananda Ishaya wrote: On Apr 10, 2012, at 2:26 AM, Thierry Carrez wrote: Jay Pipes wrote: I take it you didn't attend the glorious JSON debate of a couple of summits ago :-) Glorious it was indeed. I think the key quote was something like: Please don't bastardize my JSON with your XML crap According to my twitter, the actual quote was: Don't bring your XML filth into my JSON Vish ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Mark Nottingham http://www.mnot.net/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Image API v2 Draft 4
Jay Pipes wrote: I take it you didn't attend the glorious JSON debate of a couple of summits ago :-) Glorious it was indeed. I think the key quote was something like: Please don't bastardize my JSON with your XML crap -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Image API v2 Draft 4
APPENDIX B: Outstanding issues
...
2) How do we fit the existing 'copy_from' functionality in?
Is the v2 API retaining some equivalent of the existing
x-image-meta-location header, to allow an externally-stored
image be registered with glance?
e.g. via an image field specified on create or update:
POST /images HTTP/1.1
{external-location: s3://access:sec...@s3.amzonaws.com/image, ...}
or:
PUT /images/IMAGE_ID HTTP/1.1
{external-location: s3://access:sec...@s3.amzonaws.com/image, ...}
If so, the most straight-forward approach for copy-from would be to
follow a similar pattern with an image field such as:
POST /images HTTP/1.1
{copy-from: s3://access:sec...@s3.amzonaws.com/image, ...}
... etc.
Cheers,
Eoghan
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Image API v2 Draft 4
FWIW, Nova already has this kind of abstraction, with views and
serializers... I wasn't planning on reinventing any wheels with the 2.0
Images API implementation; just using what Nova had (and hopefully
moving it to openstack-common before bringing the code into Glance).
Best,
-jay
On 04/10/2012 06:51 AM, Doug Hellmann wrote:
On Mon, Apr 9, 2012 at 5:14 PM, Justin Santa Barbara
jus...@fathomdb.com mailto:jus...@fathomdb.com wrote:
When you're designing JSON considering only JSON, you'd
probably use {
key1: value1 } - as you have done. If you're designing
generically,
you'd probably use { key: key1, value: value1 }.
You mean we'd have to do dumb crap because XML doesn't have the
native concept of a list? ;)
XML has lists, as does Avro, ProtocolBuffers Thrift. XML supports
extensible lists, which is why the syntax is different.
You'd *think* this would work. In practice, however, it
really doesn't. Neither does (good, valid) code generation...
Of course it works! Every JAX-RS webserver does this. You just
can't start with JSON first and expect everything to magically be OK.
If you think it doesn't work, can you provide an example?
You start with an abstract model, and then check what it looks like
in JSON, in XML, in ProtocolBuffers, in Avro, in Thrift, in HPSTR,
etc... If you start with JSON, then of course it won't work. If
we're going to treat XML as an afterthought, then I'd rather we just
didn't support XML at all (and yes, I absolutely mean that - it is
good that Glance is honest that they don't support XML.)
Kevin Dangoor and Christophe de Vienne have done some work on
abstracting the view of data inside and outside of the API with
TGWebServices [1] (a TurboGears add-on) and the more recent Web
Services Made Easy [2], which is framework agnostic. I have used TGWS
in the past to create an API using SOAP and JSON (it also supports
generic XML, but we didn't need that). I found that it worked well for
our purposes at the time.
[1] http://code.google.com/p/tgws/
[2] http://packages.python.org/WSME/
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Image API v2 Draft 4
I'll let Waldon answer this, but I know that it is marked as to be
determined currently in his notes on the API...
On 04/10/2012 09:21 AM, Eoghan Glynn wrote:
APPENDIX B: Outstanding issues
...
2) How do we fit the existing 'copy_from' functionality in?
Is the v2 API retaining some equivalent of the existing
x-image-meta-location header, to allow an externally-stored
image be registered with glance?
e.g. via an image field specified on create or update:
POST /images HTTP/1.1
{external-location: s3://access:sec...@s3.amzonaws.com/image, ...}
or:
PUT /images/IMAGE_ID HTTP/1.1
{external-location: s3://access:sec...@s3.amzonaws.com/image, ...}
If so, the most straight-forward approach for copy-from would be to
follow a similar pattern with an image field such as:
POST /images HTTP/1.1
{copy-from: s3://access:sec...@s3.amzonaws.com/image, ...}
... etc.
Cheers,
Eoghan
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Image API v2 Draft 4
+1 on reusing existing code and the move
On Tue, Apr 10, 2012 at 10:47 AM, Jay Pipes jaypi...@gmail.com wrote:
FWIW, Nova already has this kind of abstraction, with views and
serializers... I wasn't planning on reinventing any wheels with the 2.0
Images API implementation; just using what Nova had (and hopefully moving
it to openstack-common before bringing the code into Glance).
Best,
-jay
On 04/10/2012 06:51 AM, Doug Hellmann wrote:
On Mon, Apr 9, 2012 at 5:14 PM, Justin Santa Barbara
jus...@fathomdb.com mailto:jus...@fathomdb.com wrote:
When you're designing JSON considering only JSON, you'd
probably use {
key1: value1 } - as you have done. If you're designing
generically,
you'd probably use { key: key1, value: value1 }.
You mean we'd have to do dumb crap because XML doesn't have the
native concept of a list? ;)
XML has lists, as does Avro, ProtocolBuffers Thrift. XML supports
extensible lists, which is why the syntax is different.
You'd *think* this would work. In practice, however, it
really doesn't. Neither does (good, valid) code generation...
Of course it works! Every JAX-RS webserver does this. You just
can't start with JSON first and expect everything to magically be OK.
If you think it doesn't work, can you provide an example?
You start with an abstract model, and then check what it looks like
in JSON, in XML, in ProtocolBuffers, in Avro, in Thrift, in HPSTR,
etc... If you start with JSON, then of course it won't work. If
we're going to treat XML as an afterthought, then I'd rather we just
didn't support XML at all (and yes, I absolutely mean that - it is
good that Glance is honest that they don't support XML.)
Kevin Dangoor and Christophe de Vienne have done some work on
abstracting the view of data inside and outside of the API with
TGWebServices [1] (a TurboGears add-on) and the more recent Web
Services Made Easy [2], which is framework agnostic. I have used TGWS
in the past to create an API using SOAP and JSON (it also supports
generic XML, but we didn't need that). I found that it worked well for
our purposes at the time.
[1] http://code.google.com/p/tgws/
[2] http://packages.python.org/**WSME/ http://packages.python.org/WSME/
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Image API v2 Draft 4
I'd really rather we supported one format, if they're not going to be equal
citizens (i.e. both generated from a common model).
I wasted a lot of time with nova's XML support; I'm sure the Java binding
was the only project ever to try to use it; we'd have been able to proceed
much faster if we'd just stuck with JSON - we now have a horrible hybrid,
where JSON is used for some calls because the XML has/had bugs.
You prefer working from a JSON model; you're doing the work; so JSON it is.
Please spend the time you would have spent on XML support on making glance
2.0 the best image server there is.
Justin
On Tue, Apr 10, 2012 at 7:47 AM, Jay Pipes jaypi...@gmail.com wrote:
FWIW, Nova already has this kind of abstraction, with views and
serializers... I wasn't planning on reinventing any wheels with the 2.0
Images API implementation; just using what Nova had (and hopefully moving
it to openstack-common before bringing the code into Glance).
Best,
-jay
On 04/10/2012 06:51 AM, Doug Hellmann wrote:
On Mon, Apr 9, 2012 at 5:14 PM, Justin Santa Barbara
jus...@fathomdb.com mailto:jus...@fathomdb.com wrote:
When you're designing JSON considering only JSON, you'd
probably use {
key1: value1 } - as you have done. If you're designing
generically,
you'd probably use { key: key1, value: value1 }.
You mean we'd have to do dumb crap because XML doesn't have the
native concept of a list? ;)
XML has lists, as does Avro, ProtocolBuffers Thrift. XML supports
extensible lists, which is why the syntax is different.
You'd *think* this would work. In practice, however, it
really doesn't. Neither does (good, valid) code generation...
Of course it works! Every JAX-RS webserver does this. You just
can't start with JSON first and expect everything to magically be OK.
If you think it doesn't work, can you provide an example?
You start with an abstract model, and then check what it looks like
in JSON, in XML, in ProtocolBuffers, in Avro, in Thrift, in HPSTR,
etc... If you start with JSON, then of course it won't work. If
we're going to treat XML as an afterthought, then I'd rather we just
didn't support XML at all (and yes, I absolutely mean that - it is
good that Glance is honest that they don't support XML.)
Kevin Dangoor and Christophe de Vienne have done some work on
abstracting the view of data inside and outside of the API with
TGWebServices [1] (a TurboGears add-on) and the more recent Web
Services Made Easy [2], which is framework agnostic. I have used TGWS
in the past to create an API using SOAP and JSON (it also supports
generic XML, but we didn't need that). I found that it worked well for
our purposes at the time.
[1] http://code.google.com/p/tgws/
[2] http://packages.python.org/**WSME/ http://packages.python.org/WSME/
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Image API v2 Draft 4
The ability to add an external image was dropped when I removed the concept of
image locations. I wanted to rethink how locations worked and didn't realize
how much I was actually removing! 'copy_from' just hasn't been fit into the
spec yet. I want both of the features to be exposed through the API, but I want
it done cleanly. This is something that we will figure out as we implement the
API, as there isn't a perfect solution right now. We definitely won't be
releasing the v2 API without these features!
Waldon
On Apr 10, 2012, at 6:21 AM, Eoghan Glynn wrote:
APPENDIX B: Outstanding issues
...
2) How do we fit the existing 'copy_from' functionality in?
Is the v2 API retaining some equivalent of the existing
x-image-meta-location header, to allow an externally-stored
image be registered with glance?
e.g. via an image field specified on create or update:
POST /images HTTP/1.1
{external-location: s3://access:sec...@s3.amzonaws.com/image, ...}
or:
PUT /images/IMAGE_ID HTTP/1.1
{external-location: s3://access:sec...@s3.amzonaws.com/image, ...}
If so, the most straight-forward approach for copy-from would be to
follow a similar pattern with an image field such as:
POST /images HTTP/1.1
{copy-from: s3://access:sec...@s3.amzonaws.com/image, ...}
... etc.
Cheers,
Eoghan
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Image API v2 Draft 4
On Tue, 2012-04-10 at 10:05 -0700, Justin Santa Barbara wrote: I wasted a lot of time with nova's XML support; I'm sure the Java binding was the only project ever to try to use it; we'd have been able to proceed much faster if we'd just stuck with JSON - we now have a horrible hybrid, where JSON is used for some calls because the XML has/had bugs. Well, hopefully the XML support has been a little better since my templates stuff went in. Either way, though, if I had the choice, I'd rip all of nova's XML support out tomorrow… -- Kevin L. Mitchell kevin.mitch...@rackspace.com ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Image API v2 Draft 4
It definitely has improved - thank you for all your work; I didn't mean to put down anyone's work here. It's simply a Sisyphean task. Either way, though, if I had the choice, I'd rip all of nova's XML support out tomorrow… As a strong supporter of XML, who thinks JSON is for kids that haven't figured out that the Easter bunny isn't real yet :-)... +1 Justin ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Image API v2 Draft 4
I'm also a strong supporter of XML. XML does a good job of lowering barriers for a key group of clients, specifically those that work with statically typed languages. It offers key benefits in terms of extensibility and validation. I'd hate to lose it. -jOrGe W. On Apr 10, 2012, at 12:57 PM, Justin Santa Barbara wrote: It definitely has improved - thank you for all your work; I didn't mean to put down anyone's work here. It's simply a Sisyphean task. Either way, though, if I had the choice, I'd rip all of nova's XML support out tomorrow… As a strong supporter of XML, who thinks JSON is for kids that haven't figured out that the Easter bunny isn't real yet :-)... +1 Justin ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Image API v2 Draft 4
I'll bring the fish On Apr 9, 2012, at 11:05 PM, Monty Taylor wrote: On 04/09/2012 04:11 PM, Jay Pipes wrote: On 04/09/2012 07:07 PM, Jorge Williams wrote: On Apr 9, 2012, at 6:03 PM, Justin Santa Barbara wrote: How about we discuss this further at the summit :-) I think that's a sensible proposal. We're not likely to reach a good conclusion here. I think my viewpoint is that even json-dressed-as-xml is fine; no end-user gives two hoots what our JSON/XML/HPSTR looks like. I'd wager most users of the EC2 API have never even seen the data representation! I take it you didn't attend the glorious JSON debate of a couple of summits ago :-) Glorious it was indeed. I'm up for round two, Only with beer. :) I still owe you a couple I think! I refuse to not be there for that. Please make sure I'm in the room. With a video camera. And a bottle of whiskey. Monty ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Image API v2 Draft 4
On Apr 10, 2012, at 2:26 AM, Thierry Carrez wrote: Jay Pipes wrote: I take it you didn't attend the glorious JSON debate of a couple of summits ago :-) Glorious it was indeed. I think the key quote was something like: Please don't bastardize my JSON with your XML crap According to my twitter, the actual quote was: Don't bring your XML filth into my JSON Vish ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Image API v2 Draft 4
APPENDIX B: Outstanding issues
4) Need to write xsds :(
This is easy if you design a model which works with XML. If you have an
XML compatible model, you can generate an XSD and a JSON model from that.
Also, it means you can just use common middleware to map XML to JSON,
rather than coding XML parsing functions.
I think the one thing you'd have to change is that XML won't allow you to
serialize a dictionary with elements as keys (e.g. { key1: value1,
key2: value2 }, you have to do this: [ { key: key1, value:
value1 }, { key: key2, value: value2 } ]
I think this is only done in the image properties.
On the downside: The JSON isn't as JSON-ic as it could be.
On the upside: You need never worry about XML again
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Image API v2 Draft 4
On 04/09/2012 12:56 PM, Justin Santa Barbara wrote:
APPENDIX B: Outstanding issues
4) Need to write xsds :(
This is easy if you design a model which works with XML. If you have an
XML compatible model, you can generate an XSD and a JSON model from
that. Also, it means you can just use common middleware to map XML to
JSON, rather than coding XML parsing functions.
Justin, what does design a model which works with XML mean?
I think the one thing you'd have to change is that XML won't allow you
to serialize a dictionary with elements as keys (e.g. { key1:
value1, key2: value2 }, you have to do this: [ { key: key1,
value: value1 }, { key: key2, value: value2 } ]
I think this is only done in the image properties.
No, the image properties have been removed in the 2.0 Images API and
replaced with the standard concept of tags:
https://docs.google.com/document/d/1rb7ZVn0Du_5NZqUyQpqUZSmv7Qd66TMHYAtvsow7LH4/edit#heading=h.y10rq9pdt27y
On the downside: The JSON isn't as JSON-ic as it could be.
In what ways?
On the upside: You need never worry about XML again
We haven't worried about it at all up until now. And Glance has been
perfectly fine without it. ;)
See you in a week!
-jay
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Image API v2 Draft 4
Justin, what does design a model which works with XML mean?
Simply avoiding the handful of things that are specific to JSON (or
specific to XML). Nothing too onerous (no angle brackets)!
I think this is only done in the image properties.
No, the image properties have been removed in the 2.0 Images API and
replaced with the standard concept of tags:
https://docs.google.com/**document/d/1rb7ZVn0Du_**
5NZqUyQpqUZSmv7Qd66TMHYAtvsow7**LH4/edit#heading=h.**y10rq9pdt27yhttps://docs.google.com/document/d/1rb7ZVn0Du_5NZqUyQpqUZSmv7Qd66TMHYAtvsow7LH4/edit#heading=h.y10rq9pdt27y
I was looking at properties in GET /schemas/image/access and GET
/schemas/access. In general, the Glance 2.0 model is very close to being
XML-compatible.
On the downside: The JSON isn't as JSON-ic as it could be.
In what ways?
When you're designing JSON considering only JSON, you'd probably use {
key1: value1 } - as you have done. If you're designing generically, you'd
probably use { key: key1, value: value1 }.
On the upside: You need never worry about XML again
We haven't worried about it at all up until now. And Glance has been
perfectly fine without it. ;)
Well yes, I agree that our XML support generally is sufficiently buggy as
to be unusable, hence unused. I don't actually care about XML, I just care
about having a well-specified API that works.
In my opinion, the way to do that is to specify a model, and we have JSON
and XML representations of that model. If we design the model right, JSON
XML both just work without any code (and less code = less bugs).
Moreover, when someone introduces another data interchange format, we
again just write one piece of middleware, one documentation generator, and
we're done. Doing this by hand for each format is simply busywork.
I don't care whether we specify the model as a Python class, Java class,
XML schema, JSON schema, or using stick figures with long arms pointing at
boxes. You can even specify it in JSON if you stick to a lowest common
denominator subset. I think the only thing you need to avoid is no
changing-at-runtime keys; I think this makes it compatible with XML, Avro,
ProtocolBuffers Thrift.
I don't think it should be a big deal for the JSON format to avoid dynamic
keys, given how much you win whenever you have to support a new format.
Incidentally, I just heard about yet another new format - apparently this
one is going to be the standard for use with node.js
- Hypertext-Powered-State-Transfer-Representation. Apparently JSON is too
complicated now - with its strict need for quote marks and multiple data
types and all that over engineering, so HPSTR just sends the values; you
just use convention over configuration to infer the keys. I trust it's not
going to be a lot of work for OpenStack to support it.
See you in a week!
Looking forward to it!
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Image API v2 Draft 4
On 04/09/2012 02:16 PM, Justin Santa Barbara wrote:
Justin, what does design a model which works with XML mean?
Simply avoiding the handful of things that are specific to JSON (or
specific to XML). Nothing too onerous (no angle brackets)!
I see, gotcha.
I think this is only done in the image properties.
No, the image properties have been removed in the 2.0 Images API and
replaced with the standard concept of tags:
https://docs.google.com/__document/d/1rb7ZVn0Du___5NZqUyQpqUZSmv7Qd66TMHYAtvsow7__LH4/edit#heading=h.__y10rq9pdt27y
https://docs.google.com/document/d/1rb7ZVn0Du_5NZqUyQpqUZSmv7Qd66TMHYAtvsow7LH4/edit#heading=h.y10rq9pdt27y
I was looking at properties in GET /schemas/image/access and GET
/schemas/access. In general, the Glance 2.0 model is very close to
being XML-compatible.
OK.
On the downside: The JSON isn't as JSON-ic as it could be.
In what ways?
When you're designing JSON considering only JSON, you'd probably use {
key1: value1 } - as you have done. If you're designing generically,
you'd probably use { key: key1, value: value1 }.
You mean we'd have to do dumb crap because XML doesn't have the native
concept of a list? ;)
On the upside: You need never worry about XML again
We haven't worried about it at all up until now. And Glance has been
perfectly fine without it. ;)
Well yes, I agree that our XML support generally is sufficiently buggy
as to be unusable, hence unused. I don't actually care about XML, I
just care about having a well-specified API that works.
I wasn't actually talking about Nova. :) Glance doesn't have ANY support
for XML at all. It's been using JSON and only JSON from its inception...
And for the record, we will absolutely NOT be generating JSON from XML
schemas. That is pure lunacy.
In my opinion, the way to do that is to specify a model, and we have
JSON and XML representations of that model. If we design the model
right, JSON XML both just work without any code (and less code =
less bugs).
I shall refer you to Keystone Legacy to see how well that strategy works
in practice.
Moreover, when someone introduces another data interchange
format, we again just write one piece of middleware, one documentation
generator, and we're done. Doing this by hand for each format is simply
busywork.
You'd *think* this would work. In practice, however, it really doesn't.
Neither does (good, valid) code generation...
I don't care whether we specify the model as a Python class, Java class,
XML schema, JSON schema, or using stick figures with long arms pointing
at boxes. You can even specify it in JSON if you stick to a lowest
common denominator subset.
In the 2.0 API we *are* specifying it in JSON. JSON Schema, specifically...
I think the only thing you need to avoid is
no changing-at-runtime keys; I think this makes it compatible
with XML, Avro, ProtocolBuffers Thrift.
That is antithetical to having dynamic, but discoverable, schemas. JSON
Schema (and XSD, fwiw) provide things like additionalProperties and
xsd:any for just this sort of thing. Making a schema entirely static
is really only useful for generating (bad and soon-to-be-outdated)
client code.
Having dynamic and discoverable schemas enables clients to respond to
backwards-compatible schema changes (like the addition of standard
properties or the addition of extra-standard additionalProperties)
without having to recompile a client or change any client code at all...
I don't think it should be a big deal for the JSON format to avoid
dynamic keys, given how much you win whenever you have to support a new
format.
By dynamic keys, are you referring to the additionalProperties? If so, I
disagree.
Incidentally, I just heard about yet another new format - apparently
this one is going to be the standard for use with node.js
- Hypertext-Powered-State-Transfer-Representation.
HPSTR? H(i)PST(e)R? Are you sure that wasn't an April Fool's Joke? :)
Best,
-jay
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Image API v2 Draft 4
On Mon, Apr 9, 2012 at 7:16 PM, Justin Santa Barbara jus...@fathomdb.comwrote:
When you're designing JSON considering only JSON, you'd probably use {
key1: value1 } - as you have done. If you're designing generically, you'd
probably use { key: key1, value: value1 }.
I, literally. die a little inside each and every time I see this kind of
JSON. Once you start producing JSON like this, you may as well just stick
with XML. Parsing it will be easier.
JSON and XML have different strengths and weaknesses, if you only allow the
common ground of functionality to be used you end up with a mediocre at
best implementation of both.
Thanks,
Kiall
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Image API v2 Draft 4
When you're designing JSON considering only JSON, you'd probably use {
key1: value1 } - as you have done. If you're designing generically,
you'd probably use { key: key1, value: value1 }.
You mean we'd have to do dumb crap because XML doesn't have the native
concept of a list? ;)
XML has lists, as does Avro, ProtocolBuffers Thrift. XML supports
extensible lists, which is why the syntax is different.
You'd *think* this would work. In practice, however, it really doesn't.
Neither does (good, valid) code generation...
Of course it works! Every JAX-RS webserver does this. You just can't
start with JSON first and expect everything to magically be OK.
If you think it doesn't work, can you provide an example?
You start with an abstract model, and then check what it looks like in
JSON, in XML, in ProtocolBuffers, in Avro, in Thrift, in HPSTR, etc... If
you start with JSON, then of course it won't work. If we're going to treat
XML as an afterthought, then I'd rather we just didn't support XML at all
(and yes, I absolutely mean that - it is good that Glance is honest that
they don't support XML.)
Even ignoring XML, I can't help but think that not having a strict
delineation between user-provided data and the structure of your document
is a pretty risky idea.
In the 2.0 API we *are* specifying it in JSON. JSON Schema, specifically...
Are JSON schemas an April Fool's joke? Once you introduce schemas, you
might as well just go with XML ;-)
I think the only thing you need to avoid is
no changing-at-runtime keys; I think this makes it compatible
with XML, Avro, ProtocolBuffers Thrift.
That is antithetical to having dynamic, but discoverable, schemas. JSON
Schema (and XSD, fwiw) provide things like additionalProperties and
xsd:any for just this sort of thing. Making a schema entirely static is
really only useful for generating (bad and soon-to-be-outdated) client code.
Having dynamic and discoverable schemas enables clients to respond to
backwards-compatible schema changes (like the addition of standard
properties or the addition of extra-standard additionalProperties)
without having to recompile a client or change any client code at all...
I couldn't disagree more: what does it mean? There's the implicit
contract underlying the interface; the semantics that underpin the syntax.
e.g. syntax: a glance image id is a string, semantics: the id is unique to
a glance installation and is used to refer to an image in REST calls.
xsd:any allows you to put elements _from another schema_ into your XML
document. That foreign schema defines the semantics of those elements.
It's schemas all the way down, giving semantics to your syntax.
If your additional properties in Glance are properly schematized, then
that's great. But true cross-representation schemas are an open problem, I
believe, so you're really painting yourself into a corner (how do you
support XML output, if you let people upload arbitrary JSON schemas?)
Incidentally, I just heard about yet another new format - apparently
this one is going to be the standard for use with node.js
- Hypertext-Powered-State-**Transfer-Representation.
HPSTR? H(i)PST(e)R? Are you sure that wasn't an April Fool's Joke? :)
Are you sure it wasn't mine? ;-)
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Image API v2 Draft 4
On 04/09/2012 05:14 PM, Justin Santa Barbara wrote:
When you're designing JSON considering only JSON, you'd probably
use {
key1: value1 } - as you have done. If you're designing generically,
you'd probably use { key: key1, value: value1 }.
You mean we'd have to do dumb crap because XML doesn't have the
native concept of a list? ;)
XML has lists, as does Avro, ProtocolBuffers Thrift. XML supports
extensible lists, which is why the syntax is different.
Extensible lists are pointless. Lists have no attributes other than
their length. I made this point a couple design summits ago... but
whatever :)
You'd *think* this would work. In practice, however, it really
doesn't. Neither does (good, valid) code generation...
Of course it works! Every JAX-RS webserver does this. You just can't
start with JSON first and expect everything to magically be OK.
I'm not aware that I said to start with JSON first and expect
everything to magically be OK. I believe I put both JSON Schema and
XSDs in the Images API 2.0 proposal?
If you think it doesn't work, can you provide an example?
I was referring specifically to the Keystone Legacy code that attempted
to generate JSON from XSDs and WADLs. But for the life of me, I can't
now find the code in GitHub that shows what I'm talking about... meh.
You start with an abstract model, and then check what it looks like in
JSON, in XML, in ProtocolBuffers, in Avro, in Thrift, in HPSTR, etc...
I'm not opposed to using an abstract model, I was just saying that the
easy as pie solution you offered of just having to create a new
generator, etc isn't in practice so easy and often leads to
hard-to-debug subtle differences in output format that aren't fixable
just be editing the abstract model...
If you start with JSON, then of course it won't work. If we're going
to treat XML as an afterthought, then I'd rather we just didn't support
XML at all (and yes, I absolutely mean that - it is good that Glance is
honest that they don't support XML.)
Glad we took the high road ;P
Even ignoring XML, I can't help but think that not having a strict
delineation between user-provided data and the structure of your
document is a pretty risky idea.
Not quite sure I follow you here... are you referring to dynamic schemas
here?
In the 2.0 API we *are* specifying it in JSON. JSON Schema,
specifically...
Are JSON schemas an April Fool's joke? Once you introduce schemas, you
might as well just go with XML ;-)
I personally find JSON Schema to be as robust, and infinitely more
readable, as XSD.
I think the only thing you need to avoid is
no changing-at-runtime keys; I think this makes it compatible
with XML, Avro, ProtocolBuffers Thrift.
That is antithetical to having dynamic, but discoverable, schemas.
JSON Schema (and XSD, fwiw) provide things like additionalProperties
and xsd:any for just this sort of thing. Making a schema entirely
static is really only useful for generating (bad and
soon-to-be-outdated) client code.
Having dynamic and discoverable schemas enables clients to respond
to backwards-compatible schema changes (like the addition of
standard properties or the addition of extra-standard
additionalProperties) without having to recompile a client or change
any client code at all...
I couldn't disagree more: what does it mean? There's the implicit
contract underlying the interface; the semantics that underpin the
syntax. e.g. syntax: a glance image id is a string, semantics: the id
is unique to a glance installation and is used to refer to an image in
REST calls.
I think you're muddying WADL and XSD above?
xsd:any allows you to put elements _from another schema_ into your XML
document. That foreign schema defines the semantics of those elements.
It's schemas all the way down, giving semantics to your syntax.
That's exactly what JSON Schema's additionalProperties allows...
If your additional properties in Glance are properly schematized, then
that's great. But true cross-representation schemas are an open
problem, I believe, so you're really painting yourself into a corner
(how do you support XML output, if you let people upload arbitrary JSON
schemas?)
They are absolutely properly schematized. They are nothing more than
false (indicating the schema is fixed) or a list of other schemas...
Incidentally, I just heard about yet another new format - apparently
this one is going to be the standard for use with node.js
- Hypertext-Powered-State-__Transfer-Representation.
HPSTR? H(i)PST(e)R? Are you sure that wasn't an April Fool's Joke? :)
Are you sure it wasn't mine? ;-)
:)
-jay
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help
Re: [Openstack] Image API v2 Draft 4
Justin,
From a JAX-RS / Java persecutive, starting with an XML schema and having that
dictate what the JSON will look like -- doesn't just make sense -- it makes
life *A LOT* easier. And a lot of services written in Java do just that.
Unfortunately, as you pointed out, this approach has the tendency to create
very unJSONic JSON -- in that case JSON is just an afterthought..it's a
second class citizen -- essentially it's XML with curly braces...and that
doesn't jive well with dynamic languages.
You can go the other route and start from JSON to create XML -- and some well
intended folks do this, but you end up in the other direction...essentially you
have JSON/, which is essentially JSON in XML form. That kind of XML sucks
and it's pretty useless if you work with static languages like Java and .Net --
where having a static (but extensible) schema is really useful.
That's the world we live in today...static languages work really well with XML
and dynamic languages work really well with JSON. In my opinion, you have to
account for both and treat both as first class citizens. I'd vote for having
an abstract model and treat the XML and JSON as different renderings. Doing
so is not easy as pie -- but it's not rocket science either.
I am totally with you on a couple of points though:
1. We do need to differentiate between user data and core attributes. Jay and
I have had debates about this before.
2. Having entirely dynamic discoverable schema, seems nice, but it has the
potential to introduce a lot of complexity. In particular, i'm not exactly
sure how to process the schema and keep the goodness that comes from using a
statically typed language. And, as you point out, it's not clear how one
would support multiple media types given that approach.
How about we discuss this further at the summit :-)
-jOrGe W.
On Apr 9, 2012, at 4:14 PM, Justin Santa Barbara wrote:
When you're designing JSON considering only JSON, you'd probably use {
key1: value1 } - as you have done. If you're designing generically,
you'd probably use { key: key1, value: value1 }.
You mean we'd have to do dumb crap because XML doesn't have the native concept
of a list? ;)
XML has lists, as does Avro, ProtocolBuffers Thrift. XML supports extensible
lists, which is why the syntax is different.
You'd *think* this would work. In practice, however, it really doesn't. Neither
does (good, valid) code generation...
Of course it works! Every JAX-RS webserver does this. You just can't start
with JSON first and expect everything to magically be OK.
If you think it doesn't work, can you provide an example?
You start with an abstract model, and then check what it looks like in JSON, in
XML, in ProtocolBuffers, in Avro, in Thrift, in HPSTR, etc... If you start
with JSON, then of course it won't work. If we're going to treat XML as an
afterthought, then I'd rather we just didn't support XML at all (and yes, I
absolutely mean that - it is good that Glance is honest that they don't support
XML.)
Even ignoring XML, I can't help but think that not having a strict delineation
between user-provided data and the structure of your document is a pretty risky
idea.
In the 2.0 API we *are* specifying it in JSON. JSON Schema, specifically...
Are JSON schemas an April Fool's joke? Once you introduce schemas, you might
as well just go with XML ;-)
I think the only thing you need to avoid is
no changing-at-runtime keys; I think this makes it compatible
with XML, Avro, ProtocolBuffers Thrift.
That is antithetical to having dynamic, but discoverable, schemas. JSON Schema
(and XSD, fwiw) provide things like additionalProperties and xsd:any for just
this sort of thing. Making a schema entirely static is really only useful for
generating (bad and soon-to-be-outdated) client code.
Having dynamic and discoverable schemas enables clients to respond to
backwards-compatible schema changes (like the addition of standard properties
or the addition of extra-standard additionalProperties) without having to
recompile a client or change any client code at all...
I couldn't disagree more: what does it mean? There's the implicit contract
underlying the interface; the semantics that underpin the syntax. e.g. syntax:
a glance image id is a string, semantics: the id is unique to a glance
installation and is used to refer to an image in REST calls.
xsd:any allows you to put elements _from another schema_ into your XML
document. That foreign schema defines the semantics of those elements. It's
schemas all the way down, giving semantics to your syntax.
If your additional properties in Glance are properly schematized, then that's
great. But true cross-representation schemas are an open problem, I believe,
so you're really painting yourself into a corner (how do you support XML
output, if you let people upload arbitrary JSON schemas?)
Incidentally, I just heard about yet another new format -
Re: [Openstack] Image API v2 Draft 4
How about we discuss this further at the summit :-) I think that's a sensible proposal. We're not likely to reach a good conclusion here. I think my viewpoint is that even json-dressed-as-xml is fine; no end-user gives two hoots what our JSON/XML/HPSTR looks like. I'd wager most users of the EC2 API have never even seen the data representation! ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Image API v2 Draft 4
Extensible lists are pointless. Lists have no attributes other than their length. I made this point a couple design summits ago... but whatever :) Looks like the Sapir-Whorf hypothesis might be true after all ;-) Let's dust off the pugil-sticks for the design summit.. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Image API v2 Draft 4
On Apr 9, 2012, at 6:03 PM, Justin Santa Barbara wrote: How about we discuss this further at the summit :-) I think that's a sensible proposal. We're not likely to reach a good conclusion here. I think my viewpoint is that even json-dressed-as-xml is fine; no end-user gives two hoots what our JSON/XML/HPSTR looks like. I'd wager most users of the EC2 API have never even seen the data representation! I take it you didn't attend the glorious JSON debate of a couple of summits ago :-) I'm up for round two, -jOrGe W. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Image API v2 Draft 4
On 04/09/2012 07:07 PM, Jorge Williams wrote: On Apr 9, 2012, at 6:03 PM, Justin Santa Barbara wrote: How about we discuss this further at the summit :-) I think that's a sensible proposal. We're not likely to reach a good conclusion here. I think my viewpoint is that even json-dressed-as-xml is fine; no end-user gives two hoots what our JSON/XML/HPSTR looks like. I'd wager most users of the EC2 API have never even seen the data representation! I take it you didn't attend the glorious JSON debate of a couple of summits ago :-) Glorious it was indeed. I'm up for round two, Only with beer. :) I still owe you a couple I think! -jOrGe W. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Image API v2 Draft 4
Hi, I have been fighting with these issues. Here is the proposed solution i am currently using on OpenStack Java SDK. *Every representation should implement a common interface* The jaxb annotations for marshalling and unmarshalling XML reside on xml implementation class The gson annotations for serialization and deserialization of JSON reside on json implementation class This approach is unobstrussive with XML/JSON representations I think 95% of the API works well mixing jaxb/gson annotations on the same implementation classes. This has another advantage, you can switch from one to another service provider sharing the same model, that's the interfaces model but the implentation. Does it make sense for you? Luis On Tue, Apr 10, 2012 at 1:11 AM, Jay Pipes jaypi...@gmail.com wrote: On 04/09/2012 07:07 PM, Jorge Williams wrote: On Apr 9, 2012, at 6:03 PM, Justin Santa Barbara wrote: How about we discuss this further at the summit :-) I think that's a sensible proposal. We're not likely to reach a good conclusion here. I think my viewpoint is that even json-dressed-as-xml is fine; no end-user gives two hoots what our JSON/XML/HPSTR looks like. I'd wager most users of the EC2 API have never even seen the data representation! I take it you didn't attend the glorious JSON debate of a couple of summits ago :-) Glorious it was indeed. I'm up for round two, Only with beer. :) I still owe you a couple I think! -jOrGe W. __**_ Mailing list: https://launchpad.net/~**openstackhttps://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~**openstackhttps://launchpad.net/~openstack More help : https://help.launchpad.net/**ListHelphttps://help.launchpad.net/ListHelp -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344 luis@ luis.gerv...@gmail.comwoorea.es ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Image API v2 Draft 4
On 04/09/2012 04:11 PM, Jay Pipes wrote: On 04/09/2012 07:07 PM, Jorge Williams wrote: On Apr 9, 2012, at 6:03 PM, Justin Santa Barbara wrote: How about we discuss this further at the summit :-) I think that's a sensible proposal. We're not likely to reach a good conclusion here. I think my viewpoint is that even json-dressed-as-xml is fine; no end-user gives two hoots what our JSON/XML/HPSTR looks like. I'd wager most users of the EC2 API have never even seen the data representation! I take it you didn't attend the glorious JSON debate of a couple of summits ago :-) Glorious it was indeed. I'm up for round two, Only with beer. :) I still owe you a couple I think! I refuse to not be there for that. Please make sure I'm in the room. With a video camera. And a bottle of whiskey. Monty ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Image API v2 Draft 4
The next draft of the v2 OpenStack Image API is available for review: https://docs.google.com/document/d/1rb7ZVn0Du_5NZqUyQpqUZSmv7Qd66TMHYAtvsow7LH4/edit. Unfortunately, there won't be time for an official session at the summit, but feel free to start a discussion through email or by using the comment system in the doc itself. I'll also be available at the summit to discuss this in an unofficial capacity. There are still a few kinks to work out, but we're finally getting started implementing this thing. Thanks to everyone who has helped out so far! Brian Waldon APPENDIX A: Major Changes From Draft 3 1) Removed concept of image locations - Replication and multiple image locations are not yet well-formed. It's unclear what information/capabilities we need in the API at the moment, so I've simplified it down to just GET /images/IMAGE_ID/file. I would prefer to keep the public-facing API as simple as possible, so maybe this belongs in an Admin-only API. We can iterate on this for the next 6 months if we need to… 2) Replaced access_type with visibility - Rather than 'public', 'private' and 'shared', visibility can be either 'public' or 'private'. Added some explanation of how 'visibility' plays with 'owner' in the concepts section of the doc. APPENDIX B: Outstanding issues Some of this stuff is hard, some I just haven't put the time into figuring out yet: 1) Does it make sense to use tags, metadata, or both? I can see cases for both, but is that overkill? 2) How do we fit the existing 'copy_from' functionality in? 3) Need to properly convey link objects in json schemas 4) Need to write xsds :( 5) What link relation do we use for subcollections like tags, access, etc? http://www.iana.org/assignments/link-relations/link-relations.xml___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
