Just my quick thought, I think moving it out from state/api into just a
top level api would be reasonable and a lot less clumsy than trying to
pull it out into an entirely separate repository.
I'm not sure if Gustavo realized that state/apiserver is the HTTP(-ish,
its really just JSON rpc over a
[Hmm, I'm not sure this got through originally, as I sent it from
my non-work gmail account]
I have a slightly different proposal, inspired by the recent
Go proposal for internal imports (http://golang.org/s/go14internal),
which currently looks like it will actually be implemented.
We move all
On Fri, Jun 27, 2014 at 4:21 PM, John Meinel j...@arbash-meinel.com wrote:
Just my quick thought, I think moving it out from state/api into just a
top level api would be reasonable and a lot less clumsy than trying to
pull it out into an entirely separate repository.
+1
I don't think the api
The API provides the business logic to Go and non-Go clients and uses the
state. This dependency could best be demonstrated, also for new maintainers
and contributors, by having the API as a top level below
github.com/juju/juju. Here it also best should provide the two packages
client and sever.
On 27 June 2014 07:51, David Cheney david.che...@canonical.com wrote:
On Fri, Jun 27, 2014 at 4:21 PM, John Meinel j...@arbash-meinel.com wrote:
Just my quick thought, I think moving it out from state/api into just a
top level api would be reasonable and a lot less clumsy than trying to
pull
On Thu, Jun 26, 2014 at 6:47 AM, Tim Penhey tim.pen...@canonical.com
wrote:
On reading the spec[1] and looking at the state documents as they are in
trunk now, I was quickly coming to the conclusion that the documents
need to change.
I agree with that, but...
Right now we have two action
+1 on an opened-ports hook tool, I've added it to the task list
On Fri, Jun 27, 2014 at 9:41 AM, William Reade william.re...@canonical.com
wrote:
Agreed. Note, though, that we'll want to give charms a way to know what
ports they have already opened: I think this is a case where
I think these are the results we are looking to get out of this exercise:
1. Have a well-defined and well-documented API that third parties may
consume.
2. Have a clean and well-documented Go implementation of an API wrapper
which third parties may reuse.
3. Make both of these easy
On Fri, Jun 27, 2014 at 3:05 AM, William Reade
william.re...@canonical.com wrote:
I think one of the biggest problems is the naming: state/api is a hackish
and minimal api client implementation, while state/apiserver is where the
actual api is defined... except the params package, which for
On Fri, Jun 27, 2014 at 5:36 AM, Nate Finch nate.fi...@canonical.com wrote:
have the code somewhere easily accessible in some repo, preferably without
needing to download the entire juju codebase.
Good point.
-eric
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or
On Thu, Jun 26, 2014 at 11:04 AM, Gustavo Niemeyer gust...@niemeyer.net wrote:
Hey Eric,
Some comments below, offering a slightly different perspective to be
used as a data point in your quest.
That was totally helpful. And with the further discussion (thanks
everyone!), I'm still hopeful
Thanks to all the responses thus far. While the discussion has been
insightful, I'm also hopeful that it will still be fruitful. :)
Understandably the responses have been focused on the main point of my
original post, splitting out the API client into its own repo.
However, there were a few
I also found this useful. This is specific to Go and more about the details
of the code itself than the abstract of the review as a whole.
https://code.google.com/p/go-wiki/wiki/CodeReviewComments
On Wed, Jun 25, 2014 at 9:31 AM, Gustavo Niemeyer gust...@niemeyer.net
wrote:
Thanks,
13 matches
Mail list logo