refactor cmd/ & create a standalone client under cmd/client/

[ilgooz]

kinda related with https://github.com/mesg-foundation/core/issues/191.

client package

• client will provide some low level features of core API that go-application does not intent to provide.
• when dealing with gRPC, it's easy to write lots of code for gRPC itself alongside actual application code. This package avoids you to write more code that you actually don't need for your program and provides a high level API for its consumers.
• client will define some go types like Service for its method's return types.
• client package will be used by cmd package and can be used by other programs as a dependency. we'll specially need this when we have some kinda XaaS with a web UI that wants to execute low level functionalities of mesg.
• note that cmd package will both use features from go-application and this new client package. e.g. for service dev command.

client.New(options ...Option) (*Client, error)

Client.ListServices(options ...ListServicesOption) ([]*Service, error)
Client.GetService(id string) (*Service, error)
Client.DeleteService(id string) error
Client.DeployService(r io.Reader) (*Service, error) // service.tar.gz.
Client.DeployServiceFromURL(url string) (*Service, error)
Client.StartService(id string) error
Client.StopService(id string) error
Client.ValidateService(r io.Reader) error // service.tar.gz.
Client.ValidateServiceFromURL(url string) error

// following will use functionalities from daemon package.
Client.StartDaemon() error
Client.StopDaemon() error // this should also stop running services
Client.DaemonStatus() (Status, error)
Client.DaemonLogs() (io.ReadCloser, error)

type Service struct {
  ID string
  Name string
  Tasks []Task
   ...
}

• Should we merge daemon features to this client package to keep things in one place? For Go, we can directly use daemon package but what if we need to create a package for another language in future and want to provide both features of daemon and service APIs? Shouldn't we merge them into a one single package then?
• I quit don't like the name client as package name. Also it doesn't make sense using client name for Daemon related functionalities... Any ideas?

refactor cmd handlers

To make them more logicless and create a CMD type that has handlers for each command.

[krhubert]

I've started to refactor cmd (#355) handlers (client refactor not included). But cmd pkg needs refactor for sure. For example, accessing all flags via cmd.Flags("flag-name").Vlaue.String method is poor.

About cmd handler I really like approach as it's in https://github.com/gohugoio/hugo - hugo was created by spf13 - author of cobra package.

Each cmd is an struct and has flags variable inside it (https://github.com/gohugoio/hugo/blob/master/commands/release.go). Also, there are no init funcs but every cmd is add explicitly, which is cool because you can track what's going on.

So I've started this and will push it on Monday, so we can sync this refactoring with the client/api usage.

[ilgooz]

@krhubert I like it. Serving each command as a struct gives a good isolation between other commands and prevents naming conflicts on functions. Since commands will never share functionality in between, separating them to their own structs is a good decision.

I can take the work for client package. :)

[ilgooz]

I gave a quick look on hugo. It doesn't have one but i think it'd be nice to define a Commander interface and make command structs to implement it. related with these lines: 1, 2.

type Commander interface {
    Command() *cobra.Command
}

var commands *cobra.Command

for commander := range []commanders {
    commands = append(commands, commander.Command())
}

cmd.AddCommand(commands...)

[ilgooz]

related with #310

[antho1404]

Check if this one is closed with this PR #444

[krhubert]

Closing.
client package is a different case and can be open in another issue.
Cmd refactoring it's done