Skip to content

Think through the API, make it more consistent #4

Description

@Kagami
  • var_int.value vs var_str.str vs var_list.list
  • net_addr.addrs vs inv.inventory vs error.vector
  • pubkey.needed vs msg.identities vs broadcast.subscriptions
  • bootstrap/connect/listen API: it's better to always use objects instead of positional arguments. (E.g. {host: "1.2.3.4", port: 8444})
  • connection pass 3 positional arguments (should it pass transport, {host, port} instead?)
  • error message fatal field is nonintuitive (better to use something like type)
  • version message version field is nonintuitive (better to use something like protoVersion)
  • version message streamNumbers field is awkward
  • High-level checkings (like connection to self detection) probably should lie in transport code
  • Exceptions in transport callbacks propogated further: do we want to auto-catch and warn about them?
  • Somehow make it clear that methods like tryDecode and validate don't throw exceptions

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions