Skip to content

Think through the API, make it more consistent #4

@Kagami

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

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