Per-Module ABCI msgs

[ebuchman]

#714 implemented per-module genesis init.

Commented on it after merge: #714 (comment)

Copying in here:

I'm not sure about this.

What makes InitGenesis different from BeginBlock and EndBlock that it gets this special treatment ?

See also my thoughts in #559 (which I don't think Jae agrees with, but anyways).

In the absence of doing this, modules should export methods that can be called by the InitChain function that is stitched together by the application and passed to SetInitChain

[cwgoes]

InitGenesis is included in the router as it uses the route name as the key which should be associated with the module genesis state in genesis.json, e.g. (where cool is the route)

"app_state": {
// (...)
"cool": {
  "trend": "ice-cold"
}
// (...)
}

The key could also be specified separately, although it should be done in a way that isn't a fixed property of the module so that modules don't accidentally overlap. Also, InitGenesis needs access to the store - to write the genesis information - so it seems to make sense to have it be a function on the instantiated keeper, not the module itself.

[ebuchman]

How is this different than the needs of BeginBlock/EndBlock for a module ?

[rigelrozanski]

(copied from previous comment)

The problem mostly lies routing the correct genesis option to the correct module. I think we want to enforce a basic structure as to how genesis information is passed from the genesis block directly to the module to handle. Right now we simply pass a json.rawmessage contained by a key with the module with the matching name, the module can parse / handle the raw message in arbitrary ways. I don't really see the advantage of customizable global application init genesis method... right now the only reason this is necessary is you are extending the standard account. Anyways let's talk more about this

What makes InitGenesis different from BeginBlock and EndBlock that it gets this special treatment ?

we need to route genesis information based on the key provided in genesis. BeginBlock/EndBlock do not need to route custom information - I also assume that BeginBlock/EndBlock handlers may have some interdependence whereas InitGenesis will not

[ebuchman]

This still doesn't really make sense to me.

Can't we put all the logic we need to in the initChainer? And we can pass in exactly the struct we need from there rather than passing bytes and then unmarshalling in the module itself.

See be05bf4#diff-f9b9d260531e0c5b8a590ab0409d237cR146, though I didn't quite finish, since I'm passing in the bytes, but we could easily give it just what it needs

[cwgoes]

IMO the implementation in be05bf4#diff-f9b9d260531e0c5b8a590ab0409d237cR146 is fine, perhaps with a helper function to access a subkey of the genesis JSON. It's a bit more code than the Router implementation, but more obvious.

By "exactly the struct" - do you mean that SDK applications should specify a complete genesis JSON struct with fields for genesis info for all of their modules? I like that, makes it clear what information is required and easy for the application to implement a "default genesis" (a la basecoind init).

[rigelrozanski]

As discussed in SDK meeting today - I think it really comes down to two use cases of the SDK - one where there is the least overhead for the developer and one where there is the most flexibility for implementation by the developer - For now let's keep it to the more flexible generic case, and in the future create a second basecoin which enforces module defining their initgenesis as a part of a pair-down less flexible basecoin

[ebuchman]

do you mean that SDK applications should specify a complete genesis JSON struct with fields for genesis info for all of their modules

Yes!

[ebuchman]

Ok let's close this for now :)