Author

Topic: [PULL] URI Support (Read 2037 times)

sr. member
Activity: 406
Merit: 256
April 21, 2011, 01:06:05 PM
#14
Quote
I really don't see why you guys care so much about removing flexibility from the URI scheme.
If you work on enough software, you come to realize that features with near-zero userbase just waste precious developer time, increase complexity costs far beyond any payback received, and wind up needlessly complicated users' lives in unexpected ways.
1. The reason there is near-zero userbase, is directly because there is near-zero support of the features.
2. I have already "wasted" my precious developer time implementing it.
3. It in no way complicates any users' lives, although removal would complicate tonal users' lives (or rather, they probably just are less likely to use Bitcoin).

I highly doubt people don't use tonal because there is no support in bitcoin.

More likely people don't use tonal because they are more comfortable with decimal.
member
Activity: 98
Merit: 13
April 21, 2011, 01:03:36 PM
#13
Quote
I really don't see why you guys care so much about removing flexibility from the URI scheme.
If you work on enough software, you come to realize that features with near-zero userbase just waste precious developer time, increase complexity costs far beyond any payback received, and wind up needlessly complicated users' lives in unexpected ways.
1. The reason there is near-zero userbase, is directly because there is near-zero support of the features.
2. I have already "wasted" my precious developer time implementing it.
3. It in no way complicates any users' lives, although removal would complicate tonal users' lives (or rather, they probably just are less likely to use Bitcoin).

Implementing first-draft software is only the first step.  That's when the programmer's job starts.  You have maintenance, debugging, support, etc.

This is CS 101 stuff, people.

legendary
Activity: 2576
Merit: 1186
April 21, 2011, 01:01:56 PM
#12
Quote
I really don't see why you guys care so much about removing flexibility from the URI scheme.
If you work on enough software, you come to realize that features with near-zero userbase just waste precious developer time, increase complexity costs far beyond any payback received, and wind up needlessly complicated users' lives in unexpected ways.
1. The reason there is near-zero userbase, is directly because there is near-zero support of the features.
2. I have already "wasted" my precious developer time implementing it.
3. It in no way complicates any users' lives, although removal would complicate tonal users' lives (or rather, they probably just are less likely to use Bitcoin).
sr. member
Activity: 294
Merit: 252
April 21, 2011, 12:43:44 PM
#11
I'm a programmer, and I wrote the C# URI implementation that's on the wiki for my program WalletBuddy.
member
Activity: 98
Merit: 13
April 21, 2011, 12:40:05 PM
#10
If you're implementing a bitcoin: URI handler and you feel that tonal/hex is not worth supporting, feel free to not write the extra few lines of code required. I really don't even care about tonal/hex, I'll never use it. However, Luke implemented the URI handler, and his condition for releasing it under the necessary license was that none of his code would be removed. If someone else wants to do extra work to rewrite the implementation without the additional feature, go ahead, but it seems stupid to me.

One it's released under an open source license, the license carries legal weight, whereas Luke's opinion does not.

Quote
I really don't see why you guys care so much about removing flexibility from the URI scheme.

If you work on enough software, you come to realize that features with near-zero userbase just waste precious developer time, increase complexity costs far beyond any payback received, and wind up needlessly complicated users' lives in unexpected ways.

It is a common fallacy of non-programmers that requesting easy-to-implement, unlikely-to-be-used features is nearly cost-free.

sr. member
Activity: 294
Merit: 252
April 21, 2011, 12:27:03 PM
#9
Luke-Jr's implementation allows for the person creating the bitcoin: URI to specify the amount in any of the following formats:

...and that implies someone parsing a bitcoin URI must support all that crap, even though 99.9% of all bitcoin users only use one of those formats.

That's how one person's crusade to support tonal winds up costing us all.

If you're implementing a bitcoin: URI handler and you feel that tonal/hex is not worth supporting, feel free to not write the extra few lines of code required. I really don't even care about tonal/hex, I'll never use it. However, Luke implemented the URI handler, and his condition for releasing it under the necessary license was that none of his code would be removed. If someone else wants to do extra work to rewrite the implementation without the additional feature, go ahead, but it seems stupid to me.

I really don't see why you guys care so much about removing flexibility from the URI scheme.
member
Activity: 98
Merit: 13
April 21, 2011, 11:46:45 AM
#8
Luke-Jr's implementation allows for the person creating the bitcoin: URI to specify the amount in any of the following formats:

...and that implies someone parsing a bitcoin URI must support all that crap, even though 99.9% of all bitcoin users only use one of those formats.

That's how one person's crusade to support tonal winds up costing us all.

sr. member
Activity: 294
Merit: 252
April 21, 2011, 09:53:55 AM
#7
It's better to keep a standard output and then have any specialized interfaces convert as needed.
This isn't about output, it's about input from ANY possible third party.

Luke-Jr's implementation allows for the person creating the bitcoin: URI to specify the amount in any of the following formats:

plain decimal - "5", "5.5", "5.00000005"
exponential decimal - "5e8", "5.5e8", "500000005e0"
plain hex - "x2D4", "xA.76"
exponential hex - "x2D4X4", "x2D40000X0"

I think this is a good thing, even though I think the hex versions look ugly. The thing is, the user will probably never see that, since the client is able to translate "x2D4X4" into 0.47448064 BTC. Remember, these are going to be links like...
Code:
legendary
Activity: 2576
Merit: 1186
April 20, 2011, 10:36:18 PM
#6
It's better to keep a standard output and then have any specialized interfaces convert as needed.
This isn't about output, it's about input from ANY possible third party.
sr. member
Activity: 406
Merit: 256
April 20, 2011, 10:34:14 PM
#5
I don't see how your first point applies, please clarify.

And second, negative effects include increased size of the client, and features to worry about keeping compatible. It's better to keep a standard output and then have any specialized interfaces convert as needed.
legendary
Activity: 2576
Merit: 1186
April 20, 2011, 10:28:03 PM
#4
It is biased. For one, NOBODY HAS ANY TONAL SUPPORT IN ANYTHING. For two, you don't clarify that supporting hexadecimal has NO NEGATIVE EFFECTS, and that people can still use decimal
sr. member
Activity: 406
Merit: 256
April 20, 2011, 10:25:57 PM
#3
Yes/No with little further information can't really be biased, Luke. You just seem to think that because the community doesn't want to add more cruft to the official client that we are all part of an "Anti-Tonal" agenda.
legendary
Activity: 2576
Merit: 1186
April 20, 2011, 08:13:47 PM
#2
This poll is biased and therefore meaningless. New polls created that are neutral.
hero member
Activity: 755
Merit: 515
April 20, 2011, 08:08:13 PM
#1
I'm very tired so I'll keep this short: https://github.com/bitcoin/bitcoin/pull/182
Please discuss hex/tonal support.  Current pull does not have it, but adding it would be easy based on Luke-jr's original patch if the community supports it.

EDIT: Out of respect to Luke-jr's polls, I am closing this one, please vote there.
https://bitcointalksearch.org/topic/poll-13-bitcoin-uri-refactor-low-level-vs-high-level-6206
https://bitcointalksearch.org/topic/poll-23-bitcoin-uri-refactor-exponents-poll-reset-apr-21-to-clarify-option-6207
https://bitcointalksearch.org/topic/poll-33-bitcoin-uri-refactor-units-poll-reset-apr-21-to-clarify-options-6208
Also, Luke-jr, please allow people to change their vote if they are convinced by the discussions in the thread.
Jump to: