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
Sorry I wasn't more clear about that. Anything you see that's a "cloud
servers" binding would in theory cover nova.
On Mar 18, 2011, at 1:12 PM, Jon Slenk wrote:
> On Fri, Mar 18, 2011 at 12:02 PM, Michael Mayo wrote:
>> On Mar 18, 2011, at 11:29 AM, Jon Slenk wro
On Mar 18, 2011, at 11:29 AM, Jon Slenk wrote:
> hi,
>
> IIUC, it looks like the Nova Dashboard uses EC2 via boto. Questions
> along those lines:
>
> (a) will the community be wanting to move people off of EC2 and
> towards OpenStack API?
I believe so. I think the ultimate goal is to primarily
rious languages.
> -S
>
> ________
> From: Michael Mayo [m...@openstack.org]
> Subject: [Openstack] Crazy Idea for API Formats
>
> All this talk about auth and making the API easy for developers to use got me
> thinking.
>
> The two most popular formats for APIs are XML and JSON.
All this talk about auth and making the API easy for developers to use got me
thinking.
The two most popular formats for APIs are XML and JSON.
XML is language neutral and sort of painful to read by a human. And writing an
XML parser sucks. It's not hard, but it's time consuming and annoying.
> But, unless I'm mistaken, there is only a single call to the auth
> server on the first request. If we go with a Swift model (which is
> similar to the proposed solution from Vish and Andy, but not quite the
> same), the auth server returns the storage-management-url after
> authenticating the us
> Good points above.
>
> Also good point :)
>
> Yup.
>
> Yes, you have a vote, and yes, it counts.
Thank you very much :)
> Would the best option be if the OpenStack API supported both auth
> mechanisms (signature, basic HTTP) and allowed the deployers to pick
> which ones were best for which
>> It depends. If you're in a busy area of a big city with 1 bar of EDGE
>> coverage on your phone, latency becomes your biggest connectivity issue. So
>> if you're only doing something with the API every 24 hours, auth could
>> reasonably be close to 50% of the time you stare in frustration c
both? It isn't that
> complex. It is also interesting that OAuth v1 was signature based, while
> OAuth v2 has moved to a token based auth system, so there is broad support in
> the general community for both methods.
>
> --
> Chuck
>
> On Thu, Mar 3, 2011 at 2:59 PM, Mi
> This is assuming that the endpoint url does not change, and is going to be
> the same for all users. It could be that the, say swift url, that you get is
> not the same as what someone else gets, based on their account, service
> level, or even current IP (for directing folks to the 'nearest'
> On Thu, Mar 03, 2011 at 01:23:07PM -0800, Michael Mayo wrote:
>>> We're also getting something else
>>> with a token server though: service discovery (via service URL headers
>>> returned with token). This can be important for auto-configuring apps
>>&g
> I agree the token round-trip may not be the best for mobile apps,
> but they can at least be cached.
This is exactly what I'm doing for our iOS app :) It still would be better if
I didn't have to do it at all, though. Even
> We're also getting something else
> with a token server though: ser
e why you would want to go that route. Using a token
> becomes important when we start talking about delegation, but let's not go
> there right now :-)
>
> -jOrGe W.
>
>
>
> On Mar 3, 2011, at 2:33 PM, Michael Mayo wrote:
>
>> Here are my thoughts, as a clien
Here are my thoughts, as a client developer:
1. Hit auth server first for token, then hit compute and storage endpoints
This is fairly simple, but there are a couple of problems with it:
a. It's not very curl or browser friendly (you have to curl the auth server
first and copy the token, which
Okay, I've littered the WebHelp with comments. There are too many different
topics in there for it to make sense as a single email to this list.
On Mar 2, 2011, at 4:33 PM, Michael Mayo wrote:
> I have no idea how to work with docbkx, and my suggestions/questions will be
>
On Wed, Mar 2, 2011 at 2:17 PM, Jorge Williams
> wrote:
> I'd prefer the comments sections so that we have a reference when we discuss.
> But hey, I'll take suggestions from anywhere :-)
>
> -jOrGe W.
>
> On Mar 2, 2011, at 11:16 AM, Michael Mayo wrote:
Should comments/suggestions go in this email thread or in the comments sections
of the web help? I hate to spam this list :)
Mike
On Mar 2, 2011, at 8:29 AM, Jorge Williams wrote:
>
> Hey guys,
>
> New version of OpenStack Compute 1.1 is out.
>
> PDF: http://docs.openstack.org/openstack-co
I like this idea, but I would suggest going with a unix timestamp in GMT
instead of /2011/xx/xx/etc.
Also, how would this effect error handling? It seems like you'd basically need
to have some sort of way to query all the server actions you've ever done
before with their HTTP responses.
On
18 matches
Mail list logo
