Proposal: Migrate definition toml files to pure go

As described in The next generation of go-storage definitions , I have migrated all template logic to https://github.com/Xuanwo/gg (except services, I will migrate next week).

During the migration, I found we do a lot of extra work to prepare data for the template. We need to parse the toml files first, and transform them, like called specs.Pairs:

func parsePairs() Pairs {
	var tp tomlPairs

	err := parseTOML(bindata.MustAsset(pairPath), &tp)
	if err != nil {
		log.Fatalf("parse: %v", err)
	}

	var ps Pairs

	for k, v := range tp {
		p := Pair{
			Name:        k,
			Type:        v.Type,
			Defaultable: v.Defaultable,
			Description: v.Description,
		}

		ps = append(ps, p)
	}

	return ps
}

Then we need to transform specs.Pairs to definitions.Pair, like:

func (p *Pair) Format(s specs.Pair, global bool) {
	p.Name = s.Name
	p.ptype = s.Type
	p.Global = global
	p.Defaultable = s.Defaultable

	p.originalDescription = s.Description
	p.Description = formatDescription(templateutils.ToPascal(p.Name), s.Description)
}

Maybe we can write all our definitions in golang directly?

var Pairs = []Pair{
    {Name: "path", Type: "string"}
}

Maybe we don’t need to transform them again and again?

With gg, we can do some simple job during generation instead prepare all data before executing the template?

One more thing:

There is no need for us to share the toml files with other languages, so it’s OK to write in golang directly.

Benefits

  • We don’t need to depends on pelletier/go-toml or kevinburke/go-bindata anymore!
  • Maybe we can remove the tools tag?
  • We can have more native development workflow, no generate step in go-storage!
  • More easier to add new fields?
  • Maybe we can also migrate serivce.toml to meta.go too?

Please give me more feedback about it!

I find it not so promising, sadly:

var Interfaces = []Interface{
	{
		Name: "appender",
		Ops: []Operation{
			{
				Name:    "create_append",
				Params:  []string{"path"},
				Results: []string{"o"},
				Description: `
will create an append object.

## Behavior

- CreateAppend SHOULD create an appendable object with position 0 and size 0.
- CreateAppend SHOULD NOT return an error as the object exist.
  - Service SHOULD check and delete the object if exists.
`,
			},
		},
	},
}

Compared to:

[appender.op.create_append]
params = ["path"]
results = ["o"]
description = """
will create an append object.

## Behavior

- CreateAppend SHOULD create an appendable object with position 0 and size 0.
- CreateAppend SHOULD NOT return an error as the object exist.
  - Service SHOULD check and delete the object if exists.
"""

And it’s may be a problem to read service’s data.

Maybe we need to simplify the internal logic instead of the config files.

This proposal makes no sense, I have gave up