|
|
|
|
|
|
|
|
|
|
|
In order to get the maximum amount of activity points possible, you just need to post once per day on average. Skipping days is OK as long as you maintain the average.
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
Luke-Jr
Legendary
 Offline
Activity: 2576
Merit: 1186
|
 |
April 21, 2011, 01:13:47 AM
Last edit: April 21, 2011, 01:38:10 AM by Luke-Jr |
|
This poll is biased and therefore meaningless. New polls created that are neutral.
|
|
|
|
|
Garrett Burgwardt
|
|
April 21, 2011, 03:25:57 AM |
|
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.
|
|
|
|
|
Luke-Jr
Legendary
Offline
Activity: 2576
Merit: 1186
|
|
April 21, 2011, 03:28:03 AM |
|
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
|
|
|
|
|
Garrett Burgwardt
|
|
April 21, 2011, 03:34:14 AM |
|
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.
|
|
|
|
|
Luke-Jr
Legendary
Offline
Activity: 2576
Merit: 1186
|
|
April 21, 2011, 03:36:18 AM |
|
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. |
|
|
|
|
BitterTea
|
|
April 21, 2011, 02:53:55 PM |
|
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... <a href=bitcoin:[address]?amount=x2D4X4>Click to donate!</a> |
|
|
|
|
xf2_org
Member
Offline
Activity: 98
Merit: 13
|
|
April 21, 2011, 04:46:45 PM |
|
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. |
|
|
|
|
|
BitterTea
|
|
April 21, 2011, 05:27:03 PM |
|
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. |
|
|
|
|
xf2_org
Member
Offline
Activity: 98
Merit: 13
|
|
April 21, 2011, 05:40:05 PM |
|
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. 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. |
|
|
|
|
|
BitterTea
|
|
April 21, 2011, 05:43:44 PM |
|
I'm a programmer, and I wrote the C# URI implementation that's on the wiki for my program WalletBuddy.
|
|
|
|
|
Luke-Jr
Legendary
Offline
Activity: 2576
Merit: 1186
|
|
April 21, 2011, 06:01:56 PM |
|
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). |
|
|
|
xf2_org
Member
Offline
Activity: 98
Merit: 13
|
|
April 21, 2011, 06:03:36 PM |
|
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. |
|
|
|
|
|
Garrett Burgwardt
|
|
April 21, 2011, 06:06:05 PM |
|
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. |
|
|
|
|
|
Poll
