I'm working on that.
Sent from my iPhone
On 13/04/2012, at 9:55 AM, Kiall Mac Innes wrote:
> Maybe RackSpace (or any other large operator..) can share some stats of the
> user-agents they see in the wild?
___
Mailing list: https://launchpad.net/~op
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 wheth
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 = "
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
___
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 wrote:
> A little fuel for the fire / entertainment before the summit:
> http://www.mnot
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 t
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"
Ac
Our XML support isn't good enough to be helpful. The reality is that our
XML support is an afterthought, so we're not getting those extensibility
and validation benefits anyway.
People want APIs that work. As a Java programmer, I'm perfectly capable of
talking to XML, JSON, ASCII or HPSTR. The
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'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,
On 04/10/2012 01: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 stron
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
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, whe
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
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
+1 on reusing existing code and the move
On Tue, Apr 10, 2012 at 10:47 AM, Jay Pipes 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 hopef
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 equival
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/2
> 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
On Mon, Apr 9, 2012 at 5: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 d
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
_
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
>>
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
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-a
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 ou
>
> 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..
_
>
> 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
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
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 hav
>
> 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 Mon, Apr 9, 2012 at 7:16 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 }.
>
I, literally. die a little inside each
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 do
>
> 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 remove
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
>
> 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 co
35 matches
Mail list logo
