-
Notifications
You must be signed in to change notification settings - Fork 3.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Lower barrier to entry for your first custom plugin #155
Comments
We have the stack.NewDefault() which builds up the middleware. The only exposure to the onion is in the tx command to wrap and sign it. Sure, we need to refactor the commands part there, to provide some helper method for wrapping with the default middleware. This is only a cleanup of the commands helper functions if I understand properly. |
Okay, need to reassess this issue pre-release of 0.7 after the cleanup and application of new helper functions - right now it appears to complicated |
Okay, dude, look at the |
I think the code is super easy now. I just wrote a module and server and client app and unit and cli tests in around 4 hours. I mean, it wasn't 30 minutes, but still, the code was not in my way. I think the hardest part is for people to understand the system well enough to work at such speeds. Thus, I think #194 would solve the remaining issues. Gonna mark this fixed unless you think that is not enough. |
* bugfix: fix race condition related to last commmit info and flush prune heights on every change * fix log * flush pruning heights * WriteSync on flush, fix flush tests * typo * fix rebase conflict
feat: implement true vesting accounts with clawback
I'd propose here to Support a simple default AppTx-like handler under 0.7
It might make sense to allow users to take advantage of a simplified generalized handler which somewhat replicates AppTx - solely for the purpose of lowering the boundary of entry for writing your very first plugin - right now dealing with all these onion peels could make your code feel like grated potatoes. Ultimately a plugin should not rely on this handler - but I think the current level of complexity should be eased into - we'll likely deter a whole wack-a-mole of folks by making our counter app look like it does in https://github.com/tendermint/basecoin/pull/154 right now. This counter example is still good and we should leave it in there, but maybe we also have a
dummy
plugin which takes advantage of a pre-designed default AppTx Handler... Thoughts?The text was updated successfully, but these errors were encountered: