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

docs via example apps #1376

Merged
merged 40 commits into from
Jun 29, 2018
Merged

docs via example apps #1376

merged 40 commits into from
Jun 29, 2018

Conversation

ebuchman
Copy link
Member

Implements #1330

@codecov
Copy link

codecov bot commented Jun 26, 2018

Codecov Report

Merging #1376 into develop will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff            @@
##           develop    #1376   +/-   ##
========================================
  Coverage    62.16%   62.16%           
========================================
  Files          103      103           
  Lines         5838     5838           
========================================
  Hits          3629     3629           
  Misses        1999     1999           
  Partials       210      210

@ebuchman ebuchman changed the title WIP: docs via example apps docs via example apps Jun 27, 2018
@ebuchman
Copy link
Member Author

This is still a WIP but a lot of the content is in place in a really good way again and I think we could merge to develop and then pick up from there.

@rigelrozanski rigelrozanski added T:Docs Changes and features related to documentation. wip labels Jun 27, 2018
Copy link
Contributor

@alexanderbez alexanderbez left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is great @ebuchman. It helped me a lot in terms of understanding the overall SDK structure. I left a few comments and questions 👍

There are still a handful of TODO's so I take it this is still a WIP?

}
```

Note it is unforgiving - it panics on nil keys!
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it desirable to panic on nil keys here? Or can we bubble an error upstream to handle gracefully...or panic?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.


We have only a single message type, so just one message-specific function to define, `handleMsgSend`.

Note this handler has unfettered access to the store specified by the capability key `keyAcc`. So it must also define items in the store are encoded.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So it must also define items in the store are encoded. A bit confusing to me.


```go
// Handle MsgSend.
// NOTE: msg.From, msg.To, and msg.Amount were already validated
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you think it might be worthwhile mentioning how and where validation occurs (i.e. What calls ValidateBasic?

sdk.Msg

PubKey crypto.PubKey
Signature crypto.Signature
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bad indentation here :)

}

// Return error result if msg Issuer is not equal to coin issuer
if !reflect.DeepEqual(metadata.Issuer, msg.Issuer) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure what the overhead of reflect is here, but do you think it'll be easier to understand and slightly more performant if we do: bytes.Equal(metadata.Issuer.Bytes(), msg.Issuer.Bytes())?

amount of coins in an account:

```go
acc := GetAccount(ctx, addr)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

acc := accountMapper.GetAccount(ctx, addr)?

the store.

Creating an AccountMapper is easy - we just need to specify a codec, a
capability key, and a prototype of the object being encoded (TODO: change to
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How do we anticipate the constructor changing?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

instead of passing in a prototype, we pass in a constructor: #1379

The PubKey is required for signature verification, but it is only required in
the StdSignature once. From that point on, it will be stored in the account.

The fee is paid by the first address returned by `msg.GetSigners()` for the first `Msg`.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see this function, but in the actual Antehandler impl, I don't see this being called? It just uses the first sig it sees from the TX.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

first sig in the tx must match first signer in the msgs

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I meant I don't see FeePayer actually being used, but I don't think it's a big deal.


Earlier, we noted that `Mappers` abstactions over a KVStore that handles marshalling and unmarshalling a
particular data type to and from the underlying store. We can build another
abstraction on top of `Mappers` that we call `Keepers`, which expose only
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👌 I really like this abstraction

accountMapper := auth.NewAccountMapper(cdc, keyAccount, &auth.BaseAccount{})
accountKeeper := bank.NewKeeper(accountMapper)
metadataMapper := NewApp3MetaDataMapper(keyMain)
feeKeeper := auth.NewFeeCollectionKeeper(cdc, keyFees)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The underlying implementation also performs serialization logic which makes it seem more of a mapper. Can Keepers also perform the same logic as Mappers? Seems like a bit of a blurry line.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

left as a TODO for now to clarify the feeKeeper (not sure if we can remove it from the base AnteHandler, or else we need to say something like we'll explain it after since we introduce the AnteHandler first

@ebuchman ebuchman mentioned this pull request Jun 28, 2018
4 tasks
alexanderbez
alexanderbez previously approved these changes Jun 29, 2018
Copy link
Contributor

@alexanderbez alexanderbez left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changes look great! I think it's good step forward indeed.

@ebuchman
Copy link
Member Author

Apps1-3 are basically complete.

Everything else still needs a bunch of work, but all the links work and every thing at least points in the direction of more information until we have time to fill things in and explain properly :)

We should spend some time on the UX before we provide full docs for the CLI. In the meantime we just point to the testnet tutorial.

We should keep working on the writing for app4-5 and the client (at least explain the LCD), and otherwise focus on fleshing out the missing parts of the spec.

Eventually, we'll want to also add a Reference section in here with no-bullshit explanations of all the components.

See some follow up notes in #1445

@ebuchman ebuchman merged commit a88b6b9 into develop Jun 29, 2018
@ebuchman ebuchman deleted the bucky/docs-core branch June 29, 2018 06:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T:Docs Changes and features related to documentation.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants