The problem I mentioned before, though, is that XML Schema brings more issues
to the table than it solves.
1) People inevitably use schema to generate bindings to [insert language], and
because of the complexity of the underlying data model of XML (Infoset), the
mapping of information items to
+1 to your +1.
I was wondering about formal definitions for the Quantum plugin APIs.
Will there be WADL definitions? I really want to use RelaxNG schemas to
validate the XML payloads (request and response) defined by the API.
Andy
-Original Message-
From: openstack-bounces+biermana=br
We neither hate nor love UUIDs, but we like them when they provide value
and we also accept alternatives. What we do hate is ambiguity and in
certain cases UUIDs help.
Look at the hrefs returned in this sample resource and picture what
you'd store in your database as unique identifier to refer
Jay is right. Standardizing on UUIDs doesn't mean that we have to expose them
to the humans on a regular basis. With the namespace variant uuid5(), it is
possible to regenerate the UUID given a namespace and a name.
The namespace could be the DNS/URL of the API service/zone and the name could
+1
Sent from my iPhone
On Jun 2, 2011, at 22:20, Jorge Williams wrote:
> It's not just about the service itself validating it, its as Joseph said,
> making sure that the data structures themselves are documented in detail to
> the client. To my knowledge there is no accepted schema language
On Thu, Jun 2, 2011 at 1:18 PM, George Reese wrote:
> I hate UUIDs with a passion.
>
> * They are text fields, which means slower database indexes
Text fields are stored on disk/in memory as bytes the same as any
integer. It's that the number of bytes needed to store it is greater,
resulting in l
It's not just about the service itself validating it, its as Joseph said,
making sure that the data structures themselves are documented in detail to the
client. To my knowledge there is no accepted schema language in JSON though
JSON schema is starting to catch on.
At the end of the day it
On Thu, Jun 2, 2011 at 1:54 PM, Rick Clark wrote:
> Hi All,
> Is it required for new openstack API's to support both JSON and XML, or
> would it be acceptable to only support JSON?
Glance currently does not support XML and I have no plans in the
immediate future to add support for it.
IMHO, JSON
I beg to differ on the value of XML to enterprise customers - My perception is
that validation of the data structure and valid values is important, but that
doesn't mean it needs to be XML. The same can be done with JSON (although
there's not the fancy validators set up for that), and JSON is es
I agree with George here. In some platforms, dealing with large integers is a
bit painful.
On Jun 2, 2011, at 11:24 AM, George Reese wrote:
> I understand they are large integer fields. But for consideration of
> portability, they are strings.
>
> Sent from my iPhone
>
> On Jun 2, 2011, at
I understand they are large integer fields. But for consideration of
portability, they are strings.
Sent from my iPhone
On Jun 2, 2011, at 21:14, Jorge Williams wrote:
>
> On Jun 2, 2011, at 12:18 PM, George Reese wrote:
>
>> I hate UUIDs with a passion.
>>
>> * They are text fields, which
I think we would lose some of the benefits of REST if we were to support a
single format. My experience is that we have two communities of customers some
of which prefer XML and others prefer JSON and we should be able to serve both
communities. Amazon handles the same problem by supporting tw
On Jun 2, 2011, at 12:18 PM, George Reese wrote:
> I hate UUIDs with a passion.
>
> * They are text fields, which means slower database indexes
They are not text fields they are large integers and you should store them as
such. Some databases offer direct support for them.
> * They are comp
Hi All,
Is it required for new openstack API's to support both JSON and XML, or
would it be acceptable to only support JSON?
Cheers,
Rick
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : h
I hate UUIDs with a passion.
* They are text fields, which means slower database indexes
* They are completely user-unfriendly. The whole "copy and paste" argument
borders on silliness
* The bursting scenario makes no sense to me. Why do two different clouds need
to agree on uniqueness of resour
The other decision we've made is that Nova will not do any aggregation.
Instead, the plan is to treat usage data as a notification and pipe it
into the notification message queue. This will allow cloud administrators
to set up external handlers to do their own aggregation, especially since
aggregat
Yeah, originally we had thought that Account != Project, but I believe
we've since changed to thinking that they're equivalent. Are you going to
update the spec, or would you like me to?
FYI, Monsyne Dragon has done a bit of work on some of this already; you
may want to sync with him for the curre
There was another specific use case, where someone with a private
OpenStack cloud was bursting into a public cloud. UUIDs would help ensure
the uniqueness of identifiers in that case.
On 5/29/11 8:43 PM, "Mark Nottingham" wrote:
>Ah -- makes sense. Thanks.
>
>On 30/05/2011, at 11:40 AM, Ed Le
On Thu, Jun 2, 2011 at 9:25 AM, Greg Holt wrote:
> On Jun 2, 2011, at 12:39 AM, Jorge Williams wrote:
>> How do you guys feel about the changes-since feature?
>> And if it is in the core shouldn't we support it in all of our APIs (images,
>> load balancers, etc.)?
>
> I don't think it'd be a good
On Jun 2, 2011, at 12:39 AM, Jorge Williams wrote:
>
> How do you guys feel about the changes-since feature?
> And if it is in the core shouldn't we support it in all of our APIs (images,
> load balancers, etc.)?
I don't think it'd be a good idea for Swift. It would require an additional
inde
I think I already beat you to it ;) At least for Glance...
https://blueprints.launchpad.net/glance/+spec/changes-since-filter
I've been waiting to see if Mr. Waldon would pick that up, since he
did such a bang-up job on the filtering and limit/order blueprints
this cycle :)
-jay
On Thu, Jun 2,
2011/6/2 Thomas Goirand :
> On 05/31/2011 12:41 AM, Chuck Short wrote:
>> As much as I would to keep the openstack packaging diff between Ubuntu
>> and Debian to a minimum, we are definitely going to be making changes
>> to the debian packaging for Ubuntu and creating a delta between the
>> two pac
On 05/30/2011 03:37 PM, Thierry Carrez wrote:
> Would this "Maintainer" field be the only delta between Ubuntu and
> Debian packages ? If yes, it might be worth to try to converge somewhere
> else...
Yes, because I sent all my patches to Soren, and he merged it (after the
Cactus release though). B
Hello everyone,
Just four weeks after the Diablo Design Summit in Santa Clara, today
sees the release of the first Diablo milestones ("diablo-1") for
OpenStack Cloud Compute (Nova) and OpenStack Image Registry and Delivery
Service (Glance).
You can find them, with a list of implemented blueprints
24 matches
Mail list logo
