Re: Splitting out state/api into its own repo

2014-06-27 Thread John Meinel
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

Fwd: Splitting out state/api into its own repo

2014-06-27 Thread roger peppe
[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

Re: Splitting out state/api into its own repo

2014-06-27 Thread David Cheney
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

Re: Splitting out state/api into its own repo

2014-06-27 Thread Frank Mueller
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.

Fwd: Splitting out state/api into its own repo

2014-06-27 Thread roger peppe
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

Re: Actions document - suggested changes

2014-06-27 Thread William Reade
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

Re: Port ranges - restricting opening and closing ranges

2014-06-27 Thread Matthew Williams
+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

Re: Splitting out state/api into its own repo

2014-06-27 Thread Nate Finch
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

Re: Splitting out state/api into its own repo

2014-06-27 Thread Eric Snow
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

Re: Splitting out state/api into its own repo

2014-06-27 Thread Eric Snow
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

Re: Splitting out state/api into its own repo

2014-06-27 Thread Eric Snow
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

Re: Splitting out state/api into its own repo

2014-06-27 Thread Eric Snow
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

Re: Thoughts to keep in mind for Code Review

2014-06-27 Thread Wayne Witzel
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,