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
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
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:
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
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 =
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
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
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
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
+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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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..
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
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
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
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
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
32 matches
Mail list logo
