Skip to content
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

Closed
rigelrozanski opened this issue Jul 5, 2017 · 4 comments
Closed

Lower barrier to entry for your first custom plugin #155

rigelrozanski opened this issue Jul 5, 2017 · 4 comments

Comments

@rigelrozanski
Copy link
Contributor

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?

@ethanfrey
Copy link
Contributor

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.

@rigelrozanski
Copy link
Contributor Author

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

@ethanfrey
Copy link
Contributor

Okay, dude, look at the fees/commands stuff... this is getting much easier now. What do you think? What is still missing to make the development easier? (besides better tutorials/docs)?

@ethanfrey
Copy link
Contributor

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.

@zramsay zramsay closed this as completed Oct 11, 2017
ParthDesai pushed a commit to ChorusOne/cosmos-sdk that referenced this issue Apr 19, 2021
alexanderbez pushed a commit that referenced this issue Apr 5, 2022
* 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
mattverse referenced this issue in mattverse/cosmos-sdk Apr 20, 2022
feat: implement true vesting accounts with clawback
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants