Service hash, sid, id naming

As discuss with @Anthony we need naming consistency for (service or id) variable. This will help us and other developers.

we are using right now:

  • serviceID in coreapi
  • hashOrSid in database

Moreover, we have Name variable in api.proto.Service struct - which probably was forgotten but is still displayed in cli.

The idea is to:

  • remove Name variable from Service struct
  • rename serviceID/hashOrSid to … we have two options:
    • reference
    • service
    • source

For example docker is calling this variable container .

And this is how they display it in the docs: (search for GET CONTAINER LOGS)

In cli:

➜  core git:(dev) ✗ docker logs -h
Flag shorthand -h has been deprecated, please use --help

Usage:	docker logs [OPTIONS] CONTAINER

We are already using service in cli:

➜  core git:(dev) ✗ ./dev-cli service logs -h
Show logs of a service

  mesg-core service logs [flags]

mesg-core service logs SERVICE

So we should use this in API as well and in the source code.

  • I’d like to keep Name but maybe change it as Title(optional)? Because it’s good human readable but small indicator about what service does. Description is kind of longer version of this title.

  • I like using generic service name in place of hash, sid or serviceID.

Why ? Name is good for documentation, this should stay, renaming could be an option but I don’t have any problem with name

I vote for Service, we also thought about Source

Because it seems to much, for example we have

hash: 0x0000
sid: ethereum
name: ?
description: ethreums is …

So what is the role of name variable?

I forgot about it adding.

I think we should keep name.
It’s a nice human-only short string about the service

name: "Ethereum ERC20 token"
sid: ethereum-erc20
description: "MESG Service to interact with an Ethereum ERC20 token"

+1 for service instead of serviceID and hashOrSid.