John Smith [ARCHIVE] on Nostr: 📅 Original date posted:2011-07-09 🗒️ Summary of this message: The author ...
📅 Original date posted:2011-07-09
🗒️ Summary of this message: The author seeks to add metadata to transactions and address book records for UI purposes, with ideas for extensible systems. Implementation options are discussed.
📝 Original message:Hello devs,
For UI purposes I'd like to be able to associate metadata to transactions
and address book records.
To be clear, this is completely client-side and will never see the block
chain.
For transactions:
- std::string description; // A description that the user can give to a
transaction, after he sent/received it, for example "ordered eggs"
For addresses:
- bool visibleInInterface; // Visible in interface; useful to hide old
addresses/labels from the lists, without removing them for lookup purposes
These are my current ideas; probably, more metadata can be useful later on
(accounting category, links to 3rd party services, etc), so an extensible
system would be nice.
Any ideas as to what would be the best place to put this, while minimizing
the core changes?
I'm aware that this could also be implemented completely inside the UI code,
but I'm not sure this is nice, as it would put database handling etc there
and would mean even more data files for the user to backup/track.
JS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110709/e9f67971/attachment.html>
🗒️ Summary of this message: The author seeks to add metadata to transactions and address book records for UI purposes, with ideas for extensible systems. Implementation options are discussed.
📝 Original message:Hello devs,
For UI purposes I'd like to be able to associate metadata to transactions
and address book records.
To be clear, this is completely client-side and will never see the block
chain.
For transactions:
- std::string description; // A description that the user can give to a
transaction, after he sent/received it, for example "ordered eggs"
For addresses:
- bool visibleInInterface; // Visible in interface; useful to hide old
addresses/labels from the lists, without removing them for lookup purposes
These are my current ideas; probably, more metadata can be useful later on
(accounting category, links to 3rd party services, etc), so an extensible
system would be nice.
Any ideas as to what would be the best place to put this, while minimizing
the core changes?
I'm aware that this could also be implemented completely inside the UI code,
but I'm not sure this is nice, as it would put database handling etc there
and would mean even more data files for the user to backup/track.
JS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110709/e9f67971/attachment.html>