You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
#### Creating, passing, claiming and using capabilities
279
279
280
-
Consider the case where `mod1` wants to create a capability, associate it with a resource (e.g. an IBC channel) by name, then pass it to `mod2` which will use it later:
280
+
Consider the case where `mod1` wants to create a capability, associate it with a resource (e.g. an IBC channel) by name, and then pass it to `mod2` which will use it later:
281
281
282
282
Module 1 would have the following code:
283
283
@@ -327,12 +327,12 @@ Proposed.
327
327
### Positive
328
328
329
329
* Dynamic capability support.
330
-
* Allows CapabilityKeeper to return same capability pointer from go-map while reverting any writes to the persistent `KVStore` and in-memory `MemoryStore` on tx failure.
330
+
* Allows CapabilityKeeper to return the same capability pointer from go-map while reverting any writes to the persistent `KVStore` and in-memory `MemoryStore` on tx failure.
331
331
332
332
### Negative
333
333
334
334
* Requires an additional keeper.
335
-
* Some overlap with existing `StoreKey` system (in the future they could be combined, since this is a superset functionality-wise).
335
+
* Some overlap with the existing `StoreKey` system (in the future they could be combined, since this is a superset functionality-wise).
336
336
* Requires an extra level of indirection in the reverse mapping, since MemoryStore must map to index which must then be used as key in a go map to retrieve the actual capability
Copy file name to clipboardExpand all lines: docs/architecture/adr-010-modular-antehandler.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -29,7 +29,7 @@ Pros:
29
29
Cons:
30
30
31
31
1. Improves granularity but still cannot get more granular than a per-module basis. e.g. If auth's `AnteHandle` function is in charge of validating memo and signatures, users cannot swap the signature-checking functionality while keeping the rest of auth's `AnteHandle` functionality.
32
-
2. Module AnteHandler are run one after the other. There is no way for one AnteHandler to wrap or "decorate" another.
32
+
2. Module AnteHandlers are run one after the other. There is no way for one AnteHandler to wrap or "decorate" another.
This is an example workflow for a user that wants to implement custom antehandler logic. In this example, the user wants to implement custom signature verification and change the order of antehandler so that validate memo runs before signature verification.
160
+
This is an example workflow for a user who wants to implement custom antehandler logic. In this example, the user wants to implement custom signature verification and change the order of antehandler so that validate memo runs before signature verification.
161
161
162
162
##### User Code
163
163
@@ -192,7 +192,7 @@ In addition, this approach will not break any core Cosmos SDK API's. Since we pr
192
192
193
193
Allow Decorator interface that can be chained together to create a Cosmos SDK AnteHandler.
194
194
195
-
This allows users to choose between implementing an AnteHandler by themselves and setting it in the baseapp, or use the decorator pattern to chain their custom decorators with the Cosmos SDK provided decorators in the order they wish.
195
+
This allows users to choose between implementing an AnteHandler by themselves and setting it in the baseapp, or using the decorator pattern to chain their custom decorators with the Cosmos SDK provided decorators in the order they wish.
196
196
197
197
```go
198
198
// An AnteDecorator wraps an AnteHandler, and can do pre- and post-processing on the next AnteHandler
0 commit comments