onds, the collected samples are aggregated and
> saved. There is a web-based viewer for the resulting call graphs (using
> d3.js)
Cheers,
--
Mark Nottingham http://www.mnot.net/
___
Mailing list: https://launchpad.net/~openstack
Post to
s the concepts are solidified.
>
> Liem
>
> -Original Message-
> From: openstack-bounces+liem_m_nguyen=hp@lists.launchpad.net
> [mailto:openstack-bounces+liem_m_nguyen=hp@lists.launchpad.net] On Behalf
> Of Mark Nottingham
> Sent: Tuesday, June 12, 2012 8:43 PM
&
t; My two cents,
>
>- Gabriel
>
>> -Original Message-
>> From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net
>> [mailto:openstack-
>> bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of
>> Mark Nottingham
>>
OpenStack projects isn't good
enough.
I.e., we're not building the APIs just for Horizon; they're for lots of folks,
and subtle semantics -- even when well-documented, much less when they're not
-- are often misunderstood.
Cheers,
--
Mark Nottingham http://www.mnot.net/
s on and generally agree, but
> when it comes to API features... I feel *very* strongly.
>
> All the best,
>
>- Gabriel
>
>
>> -Original Message-
>> From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net
>> [mailto:openstack-
>>
this is over TLS,
right? Sorry I didn't see that earlier.
P.P.S If it's not too late, drop the X- from that header!
<http://tools.ietf.org/html/draft-ietf-appsawg-xdash-05>
--
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
add, replace, etc. methods), but that's just some sugar on
top.
BTW, whether we use PUT or PATCH, we should be using conditional requests w/
strong validators and 412/428 status codes as necessary.
Cheers,
P.S. Full disclosure: I've recently been asked to take over editing that draf
On 24/05/2012, at 10:06 PM, Brian Waldon wrote:
>
> On May 24, 2012, at 4:12 AM, Mark Nottingham wrote:
>
>> The other limitation is having defined and registered patch formats. The
>> IETF is currently working on one for JSON; it should be progressing soon.
>>
ods.html>).
The other limitation is having defined and registered patch formats. The IETF
is currently working on one for JSON; it should be progressing soon.
<http://tools.ietf.org/html/draft-ietf-appsawg-json-patch>
Cheers,
--
Mark Nottingham http://www.mnot.net/
red, we may need to
restructure the presentation of the registries, and possibly introduce more
process. However, that shouldn't change the basic approach.
Cheers,
extension-registry.md
Description: Binary data
extensions.md
Description: Binary data
--
Mark Nottingham http://www.mno
rit-Project: openstack/nova
> Gerrit-Branch: master
> Gerrit-Owner: mnot
> Gerrit-Reviewer: Devin Carlen
> Gerrit-Reviewer: SmokeStack
> Gerrit-Reviewer: mnot
--
Mark Nottingham
http://www.mnot.net/
___
Mailing list: https://launchp
irst thing Monday morning as well as on a panel
> about TryStack Thursday afternoon and would love feedback.
Yes. I think the api.openstack.org is great and definitely moving in the right
direction; should be an interesting discussion.
Cheers,
--
Mark Nottingham
http://www.mnot.net/
ost and in terms of causing
problems down the road.
I'm not talking about *removing* XML from the current APIs that ship it, BTW;
at most I'd like to see us:
1. Not require XML for new APIs, and
2. Talk about deprecating XML support in current ones (i.e., still support it,
but de-empha
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
deal with issue 2. As things stand today though, I don't thing that we
> are even remotely there yet.
Sure. The question I'd ask, then, is it worth making our APIs seriously more
complex, hard to develop, understand, maintain, test, document, etc. in the
meantime, just to allow static language users to have their IDEs help them.
Something that the dynamic folks have gotten pretty used to living without.
Cheers,
--
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
question of completeness of translations.
> Piggybacking on the awesome Launchpad Translations community always gave
> us great coverage. It's more a code support and CI integration issue.
>
> ___
> Mailing list: https://launc
;
> 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
there is, it'd be better expressed as a new Cache-Control request directive
(e.g., Cache-Control: authoritative), next time things get revised.
Anyway, not a big deal, as it's already out there.
Cheers,
--
Mark Nottingham http://www.mnot.net/
___
On 31/01/2012, at 4:45 AM, Caitlin Bestler wrote:
> Mark Nottingham asked:
>
>> Why not just use
>> Cache-Control: no-cache?
>
>> That way, intervening caches will do the right thing too...
>
>
> Even with no caching anywhere you still have N replic
orage backend just relies on the strong read-after-write
> > consistency).
> >
> > - The file system checker needs a way to identify lost objects.
> >
> > Here the S3 backend just relies on the durability guarantee that
> > effectively no object wil
/2011, at 11:25 AM, Nati Ueno wrote:
> Hi Mark
>
> This is cool!
> Could you apply this for OpenStack WADL?
> Could you generate parameter list from XSD with XSLT?
>
> 2011/10/27 Mark Nottingham :
>> Example output at:
>> http://mnot.github.com/wadl_stylesheets/
to a message queue. Agents pick up the changes and send them
> on to subscriber endpoints. Not that hard.
Again, that's a big assertion to make. I'd rather evaluate the tools based upon
the use case, rather than arguing by assertion.
Thanks,
--
Mark Nottingham ht
Example output at:
http://mnot.github.com/wadl_stylesheets/
Cheers,
On 28/10/2011, at 9:55 AM, Mark Nottingham wrote:
> FWIW, a long time ago* I wrote an XSLT to generate HTML docs from WADL -- see:
> https://github.com/mnot/wadl_stylesheets
>
> I haven't maintained
On 28/10/2011, at 2:39 AM, Bryan Taylor wrote:
> On 10/26/2011 11:19 PM, Mark Nottingham wrote:
>>> To be truly RESTful at the level of the Fielding article (which I
>>> actually think is the best description of HATEOAS there is) you
>>> shouldn't have these
;>> Sounds awesome!
>>>>>
>>>>> I've done an application like this in the past where an entire web UI was
>>>>> data driven using a custom IDL. It had to have presentation hints
>>>>> associated with it (acceptable valu
t;>>
>>> ___
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to : openstack@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help : https://help.l
having the interface being machine-consumable at
runtime -- see the previous discussion on versioning and extensibility -- but
WADL isn't really designed for this. I'm sketching up something more
appropriate, and will be able to talk about it soon (hopefully).
Cheers,
>
> -S
>
&
On 27/10/2011, at 3:19 PM, Mark Nottingham wrote:
>> I floated the idea a while back that we get rid of variants altogether and
>> instead use an HTML representation to offer the user a choice of how to view
>> the information that includes elements with JSON and XML form
ese are reasonable things to do with it.
What do you mean by "machine consumption" -- are you saying that you want
clients to automatically generate bindings?
Cheers,
--
Mark Nottingham http://www.mnot.net/
___
Mailing list: https
On 27/10/2011, at 5:19 AM, Bryan Taylor wrote:
> On 10/24/2011 11:20 PM, Mark Nottingham wrote:
>> tl;dr
> Much omitted, since it's long... I agree strongly with 98% of what you are
> saying.
>
> I'll focus on the variants here. I'd rather just get rid of
n the discussion of hypertext-based APIs was that if you do it
correctly, you only present the client with the links that are valid for their
state, thereby naturally enforcing the state machine. Of course, you still need
to be able to document things so that consumers can get an
in C) based on the recent work.
I'm wary of assigning resources the magical name "collection" with the
implication that you can assume very specific behaviours regarding query
parameter parsing, etc.; it's very tightly coupled.
Cheers,
--
Mark Nottingham http://www.mnot.net/
#x27;s not to say I'm married to it; I just want to put it out there for
consideration. The really important thing, to me, is that we very carefully
document what our expectations for API clients are; if they can trust that a
URI under "/v1/" will never change in a backwards-inco
gt; --
> Kevin L. Mitchell
>
> This email may include confidential information. If you received it in error,
> please delete it.
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.ne
On 13/10/2011, at 5:42 PM, Bryan Taylor wrote:
> On 10/12/2011 07:55 PM, Mark Nottingham wrote:
>>> The duplication of effort can be solved by having an intermediary do the
>>> translation. Repose already does this.
>>>
>> That's where there be dragon
t resource of the other.
> This email may include confidential information. If you received it in error,
> please delete it.
>
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
>
On 12/10/2011, at 6:10 PM, Bryan Taylor wrote:
> On 10/11/2011 09:02 PM, Mark Nottingham wrote:
>> While we're talking about versions -- I see that the 1.1 docs allow both URI
>> and media type versioning. That makes me pretty uncomfortable, for a few
>> reasons:
>
I've started a list of proposed goals here:
http://wiki.openstack.org/Governance/Proposed/APIGoals
Please pile on...
On 11/10/2011, at 11:53 PM, Jay Pipes wrote:
> On Tue, Oct 11, 2011 at 1:11 AM, Mark Nottingham wrote:
>> +1 (sorry for the lag, been travelling).
>>
te, and Hybrid Clouds - @enStratus -
> http://www.enstratus.com
> To schedule a meeting with me: http://tungle.me/GeorgeReese
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
>
to a client. That isn't being done
now, AFAICT.
This isn't to say that there isn't a place for media type versioning in the
APIs, just that it fulfils a very different function (managing change in
representation formats).
Cheers,
--
Mark Nottingham http://www.mnot.
timate uses in
the update case.
There are cases where it's necessary to be prescriptive, of course (e.g., to
have a sane approach to versioning).
Cheers,
--
Mark Nottingham http://www.mnot.net/
___
Mailing list: https://launchpad.net/~openstac
hey aren't there) or update things (if
they are).
POST can do anything; there may be another method that has more specific
semantics that are appropriate, but because of its escape-hatch nature, there
really isn't anything it isn't allowed to do, semantically.
Cheers,
--
Mark No
>>
>> This email may include confidential information. If you received it in
>> error, please delete it.
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@list
__
> 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/
My .02 -
Pretty much every Open Source project I've been involved in has two lists set
up like this, once they get off the ground. Like others have said, it doesn't
mean the groups separate, only that the discussions are easier to follow...
Cheers,
--
Mark Nottingham http://ww
support matching on header values:
> Vary: Link:*;rel="keystone-token"
>
>
> On 9/4/11 9:51 PM, "Mark Nottingham" wrote:
>
>> Good point; Link makes more sense on a response.
>>
>> Cheers,
>>
>>
>> On 05/09/2011, at 12:49 PM, B
>> Love it.
>>
>>
>> Link:
>> <https://keystone.server/tokens/fa8426a0-8eaf-4d22-8e13-7c1b16a9370c>;
>> rel="keystone-token"
>>
>>
>> Fixed: s/tenants/tokens/ (my bad).
>>
>>
>> On 9/4/11 7:40 PM, "Ma
normal keystone servers and proceed.
> This email may include confidential information. If you received it in error,
> please delete it.
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.ne
of Gerrit. If you
> are interested in helping Monty and Jim make the Gerrit UI prettier
> and saving reviewers eyeballs, please do contact me.
>
> Cheers,
> -jay
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to
Hey,
Sorry it took a while to get back; other things intervened.
On 03/06/2011, at 11:56 PM, Jorge Williams wrote:
>
> On Jun 2, 2011, at 10:41 PM, Mark Nottingham wrote:
>
>> The problem I mentioned before, though, is that XML Schema brings more
>> issues to the
d set, UNLESS it contains
*/*;q=0 (which basically says "don't send me anything else.").
See:
http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-14#section-8.4.16
vs
http://tools.ietf.org/html/draft-ietf-httpbis-p2-semanti
>> IMHO, JSON can be validated just as easily as XML. Simply
>> json.loads(req.body) and then, if parsing succeeds, compare the
>> mapping against a model. No need for XSDs, WADLs, or any other
>> acronym.
>>
>> -jay
>
>
> _____
> Thanks,
> Anne
> Anne Gentle
> a...@openstack.org
> my blog | my book | LinkedIn | Delicious | Twitter
> On Sun, May 29, 2011 at 8:01 PM, Mark Nottingham wrote:
> <http://docs.openstack.org/cactus/openstack-compute/developer/openstack-compute-api-1.1/os-compute-devguide-
Ah -- makes sense. Thanks.
On 30/05/2011, at 11:40 AM, Ed Leafe wrote:
> On May 29, 2011, at 9:01 PM, Mark Nottingham wrote:
>
>> WIth regards to UUIDs -- I'm not sure what the use cases being discussed are
>> (sorry for coming in late), but in my experience UUIDs are
xamples, the HTTP response headers and/or request headers
are omitted. IME this often causes confusion and bugs, because developers don't
understand the context of the request or response.
- Finally, could you possibly make the PDF version NOT have grey backgrounds
for all of the example
f>
April 25, 2011 version
2. <https://bugs.launchpad.net/nova>
--
Mark Nottingham http://www.mnot.net/
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchp
56 matches
Mail list logo
