// 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
