brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Heneveld <alex.henev...@cloudsoftcorp.com>
Subject Re: [DISCUSS] Create repo for new deliverable: CLI <- client project name and language binding discussion
Date Thu, 26 Nov 2015 17:08:02 GMT

@Robert-

Thx for explanation.  For me it's about emphasis.  The message of this 
proposal for code-browsers is:

* brooklyn-client is *the* main client you should use; look at it and 
you'll see it's a cli, and it happens to be written in go, but that's 
not relevant at a high level
* there is also a ui, obviously at brooklyn-ui
* there is a rest client binding for java but currently it's buried; 
these might be promoted at some point but they'd never be the main 
client project; I expect they'd be called something like 
brooklyn-client-rest-bindings

I think we sometimes overcomplicate things for people when we try to 
precisely describe everything rather than taking a stand. #toomanyphds

@Hadrian-  I had no intention to close the VOTE; I was simply 
redirecting discussion off the VOTE thread.  +1 to reaching consensus in 
which case I think the process should be Robert replying to the VOTE 
thread indicating so.

Best
Alex


On 26/11/2015 16:53, Robert Moss wrote:
> My original vote (+1 separate repo named brooklyn-cli) still stands.  I was
> raising the question since an amendment to the name was raised, whether we
> should take into account that other clients exist i.e the the Java rest
> client, and consider the possibility of reflecting this with e.g
> brooklyn-go-client and brooklyn-java-client repos, and any other language
> bindings in future following the same pattern.  It just so happens that the
> brooklyn-go-client would have a CLI inside it.
>
> On 26 November 2015 at 16:36, Hadrian Zbarcea <hzbarcea@gmail.com> wrote:
>
>> Alex moved this to a discuss, which I think is a bit confusing. I would
>> prefer to keep the vote open even if it takes longer.
>>
>> Robert, since you are the one objecting, do you disagree with:
>> a. The fact that we need a separate repo for the go client
>> b. Don't like the name
>>
>> What we put it in the repo is up to us, we can discuss at length later.
>> Infra won't create the repo with the given name unless we ask for it. If
>> you object to a), I will cancel the thread, if you object to b) hopefully
>> we can reach a quick agreement and keep the vote on track. If it's
>> something else, it should not be discussed during the [vote].
>>
>> My $0.02,
>> Hadrian
>>
>>
>> On 11/26/2015 06:09 AM, Robert Moss wrote:
>>
>>> It was, in fact, language bindings I was talking about.  The go client has
>>> both language bindings and a CLI in one project.  The Java client I was
>>> referring to was the rest client not the server CLI, which is just
>>> bindings.  What I was alluding to was that it might be good to have
>>> several
>>> language bindings in separate repos and a distinction made between client
>>> and CLI.
>>>
>>> On 26 November 2015 at 10:51, Alex Heneveld <
>>> alex.heneveld@cloudsoftcorp.com
>>>
>>>> wrote:
>>>>
>>>
>>>> // moving from VOTE to DISCUSS thread
>>>>
>>>> *Re what will happen to the existing java client:*
>>>>
>>>> The Java CLI is for running the *server*.  It will live in server
>>>>
>>>>
>>>> *Re 'brooklyn-client' or 'brooklyn-client-cli' (or
>>>> ***'brooklyn-go-client'
>>>> or 'brooklyn-cli' which I don't like):**
>>>>
>>>> The important thing to differentiate in the repo name (ie the top level I
>>>> think) is whether something is for the server, for the CLI client, for
>>>> the
>>>> UI, etc.  Language isn't important so I don't like `go-client` --
>>>> although
>>>> it's nice that the top-level usage/role/repo distinctions do align with
>>>> language distinctions!
>>>>
>>>> Where the language *is* relevant in the name if we're making language
>>>> bindings e.g. to facility client code using the REST API.  We have this
>>>> currently for Java and only in the "rest-client" project.  This could be
>>>> renamed "rest-client-java-bindings".  (On a side note it is proposed that
>>>> this go into brooklyn-server for now; semantically this is wrong as it
>>>> isn't server code ... but to do otherwise would result in a lot of
>>>> cross-project PR's.  I don't think it's worth tidying this now; maybe if
>>>> we
>>>> have lots of language bindings then maybe it would be -- e.g. a
>>>> `brooklyn-client-rest-bindings` top-level repo.)
>>>>
>>>> It would be more descriptive for the CLI repo to have
>>>> `brooklyn-client-cli` and I'm not opposed to that but it seems
>>>> long-winded
>>>> for a project name.  When I hear "client" as a devops context my default
>>>> is
>>>> a client command-line tool; if it's any other type of client -- eg a UI
>>>> or
>>>> language binding -- it would typically be named differently.  As in
>>>> `brooklyn-ui` and `brooklyn-client-rest-bindings`.
>>>>
>>>>
>>>> *Code-gen:*
>>>>
>>>> I really like Swagger codegen for creating language bindings / client
>>>> stub
>>>> libraries.  With the recent Swagger upgrade I think we do now generate
>>>> compliant JSON, exposed through the REST API, and so I think it would be
>>>> a
>>>> simple matter to auto-generate binding stubs for most languages.  I've
>>>> not
>>>> tried this with Brooklyn but if someone does, and wants to add a page to
>>>> the docs that would be fantastic.  (And maybe in future we auto-gen
>>>> `brooklyn-rest-client-bindings` for many languages; but not a high
>>>> priority.)
>>>>
>>>> Best
>>>> Alex
>>>>
>>>>
>>>> On 26/11/2015 10:05, Andrea Turli wrote:
>>>>
>>>> I agree with Robert, that's why I still `+1`  `brooklyn-cli` over
>>>>> `brooklyn-client`
>>>>>
>>>>> I'm tempted to suggest `brooklyn-go-client`. What happens to the
>>>>> existing
>>>>>
>>>>> Java client, which is not a CLI?  Does it deserve its own repo too?
>>>>>> What
>>>>>> about future language clients?
>>>>>>
>>>>>> If the brooklyn rest API will be fully Swagger compliant I think
a good
>>>>>>
>>>>> documentation on how how to generate clients in different languages
>>>>> starting from the same YAML spec using swagger-codegen will be enough,
I
>>>>> think. This will offer a good integration with other ecosystems and it
>>>>> will
>>>>> not require brooklyn community to support all the languages available
>>>>> out
>>>>> there.
>>>>>
>>>>> Cheers,
>>>>> Andrea
>>>>>
>>>>>
>>>>>


Mime
View raw message