Based on feedback from Rick Harding, amongst others,
we have made some changes to the proposed charm
store API. The new document is here:
https://docs.google.com/a/canonical.com/document/d/1TgRA7jW_mmXoKH3JiwBbtPvQu7WiM6XMrz1wSrhTMXw
The most significant change is that all endpoints
refer just to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 14-07-15 10:17 AM, roger peppe wrote:
> The most significant change is that all endpoints refer just to a
> single charm or bundle, rather than being "bulk" calls as they were
> before.
That sounds like the opposite of what juju-reports wants. Doe
On Tue, 15 Jul 2014, Aaron Bentley wrote:
> On 14-07-15 10:17 AM, roger peppe wrote:
> > The most significant change is that all endpoints refer just to a
> > single charm or bundle, rather than being "bulk" calls as they were
> > before.
>
> That sounds like the opposite of what juju-reports want
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 14-07-15 11:43 AM, Richard Harding wrote:
> On Tue, 15 Jul 2014, Aaron Bentley wrote:
>
>> On 14-07-15 10:17 AM, roger peppe wrote:
>>> The most significant change is that all endpoints refer just
>>> to a single charm or bundle, rather than being
On Tue, 15 Jul 2014, Aaron Bentley wrote:
> I am surprised that juju-reports was not considered a known client. I
> certainly made many comments on the first draft of the original proposal.
It is listed under known clients in the spec, and we mentioned your request
down below. What we lack is y
On 15 July 2014 21:07, Aaron Bentley wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 14-07-15 11:43 AM, Richard Harding wrote:
>> On Tue, 15 Jul 2014, Aaron Bentley wrote:
>>
>>> On 14-07-15 10:17 AM, roger peppe wrote:
The most significant change is that all endpoints refer j
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
To echo what Aaron says, in any distributed system, it is almost always a
mistake not to design for bulk api calls. Even if you don't think they are
needed for the initial use cases, they will almost always be needed at some
point later. It is trivial
...
> To echo what Aaron says, in any distributed system, it is almost always a
> mistake not to design for bulk api calls. Even if you don't think they are
> needed for the initial use cases, they will almost always be needed at some
> point later. It is trivial to use a bulk call with a single
[resending with correct From address]
On 15 July 2014 21:07, Aaron Bentley wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 14-07-15 11:43 AM, Richard Harding wrote:
>> On Tue, 15 Jul 2014, Aaron Bentley wrote:
>>
>>> On 14-07-15 10:17 AM, roger peppe wrote:
The most significa
On Wed, 16 Jul 2014, John Meinel wrote:
> ...
>
>
> > To echo what Aaron says, in any distributed system, it is almost always a
> > mistake not to design for bulk api calls. Even if you don't think they are
> > needed for the initial use cases, they will almost always be needed at some
> > point l
On Wed, Jul 16, 2014 at 9:51 AM, Ian Booth wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> To echo what Aaron says, in any distributed system, it is almost always a
> mistake not to design for bulk api calls. Even if you don't think they are
> needed for the initial use cases, they w
On 16 July 2014 12:43, William Reade wrote:
> On Wed, Jul 16, 2014 at 9:51 AM, Ian Booth wrote:
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> To echo what Aaron says, in any distributed system, it is almost always a
>> mistake not to design for bulk api calls. Even if you don't thi
On Tue, Jul 15, 2014 at 7:05 PM, Richard Harding
wrote:
> It is listed under known clients in the spec, and we mentioned your request
> down below. What we lack is your specific use cases as no one working on
> the spec is knowledgeable about how you're using the api.
Besides what others have sa
On Wed, Jul 16, 2014 at 12:10 PM, Richard Harding <
rick.hard...@canonical.com> wrote:
>
> I'm not against having any bulk api calls but we've got a handful of
> clients and the one use case we've found for them is Aaron's work which I
> think we can better address with our current scheme anyway as
On 16 July 2014 13:32, William Reade wrote:
> On Wed, Jul 16, 2014 at 12:10 PM, Richard Harding
> wrote:
>>
>> I'm not against having any bulk api calls but we've got a handful of
>> clients and the one use case we've found for them is Aaron's work which I
>> think we can better address with our
On Wed, 16 Jul 2014, Gustavo Niemeyer wrote:
> On Tue, Jul 15, 2014 at 7:05 PM, Richard Harding
> wrote:
> > It is listed under known clients in the spec, and we mentioned your request
> > down below. What we lack is your specific use cases as no one working on
> > the spec is knowledgeable abou
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 14-07-15 06:05 PM, Richard Harding wrote:
> On Tue, 15 Jul 2014, Aaron Bentley wrote:
> What we lack is your specific use cases as no one working on the
> spec is knowledgeable about how you're using the api.
I'm happy to participate in any discus
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 14-07-16 03:00 AM, roger peppe wrote:
> On 15 July 2014 21:07, Aaron Bentley
> wrote: FWIW, it would be easy to provide a bulk endpoint for
> charm/bundle metadata in addition to the existing path-based
> calls.
>
> We could define:
>
> meta/$end
18 matches
Mail list logo