Jonas Schnelli [ARCHIVE] on Nostr: đź“… Original date posted:2017-03-06 đź“ť Original message:I like the BIP. It can ...
đź“… Original date posted:2017-03-06
đź“ť Original message:I like the BIP. It can reduce workload during implementation on both sides of the API and it allows to show the user more data without implementing tons of proprietary APIs.
It’s not directly Bitcoin specific (example: BIP32 is also not Bitcoin specific), but I think a BIP is the right way for this.
>
>> Apart from that, my feeling is that it could be simplified. Is
>> longpolling useful?
>
> I would think so, at least for Bitcoin since rates can change significantly in
> a short period of time (or can they anymore? I haven't really watched lately.)
Long polling is a simple push concept that works on most type of network configurations (NAT, proxy, etc.).
The only concern I see here is that an public API will quickly fill up the maximum allowed httpd connections.
But it’s solvable.
>
>> And is the historical rate thing really necessary for typical applications?
>
> When displaying historical transactions, it doesn't really make sense to use
> the current market rate, but rather the market rate at the time the payment
> was made. While wallets might simply cache it with the transaction, it would
> be perhaps nicer if it could be automatically restored for seed-only
> recoveries. In any case, if a service/wallet doesn't want to provide/use
> historical information, it can simply not implement that part.
I’m also not sure how useful historical datapoint are. I don’t think the use case where someone wants to restore from a seed and get all exchange rates during the time of the payment is something users are looking for.
However, It’s optional.
>
>> If yes, the client should be allowed to decide on which time scale the
>> data should be. (tick, min, hour, day, ...) That goes together with
>> clearly defining the type field (something like low, high, open, close,
>> but without flexibility). Think of a candle-stick chart basically.
>
> How is the current draft insufficient for this?
>
>> Also, pushing may be more appropriate for "current" rates than polling.
>> Then no polling interval is necessary. On the other hand, this adds
>> complexity in other places, e.g., state.
>
> Pushing is what longpolling does.
Agree with Luke. A „real“ push (though I’d say long-polling is the real push, AFAIK it’s also the technique behind Apple’s iOS push channel) would require a complex server setup that complicates many things like load-balancer, mem-caching, etc.
</jonas>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170306/ec223a69/attachment.sig>;
đź“ť Original message:I like the BIP. It can reduce workload during implementation on both sides of the API and it allows to show the user more data without implementing tons of proprietary APIs.
It’s not directly Bitcoin specific (example: BIP32 is also not Bitcoin specific), but I think a BIP is the right way for this.
>
>> Apart from that, my feeling is that it could be simplified. Is
>> longpolling useful?
>
> I would think so, at least for Bitcoin since rates can change significantly in
> a short period of time (or can they anymore? I haven't really watched lately.)
Long polling is a simple push concept that works on most type of network configurations (NAT, proxy, etc.).
The only concern I see here is that an public API will quickly fill up the maximum allowed httpd connections.
But it’s solvable.
>
>> And is the historical rate thing really necessary for typical applications?
>
> When displaying historical transactions, it doesn't really make sense to use
> the current market rate, but rather the market rate at the time the payment
> was made. While wallets might simply cache it with the transaction, it would
> be perhaps nicer if it could be automatically restored for seed-only
> recoveries. In any case, if a service/wallet doesn't want to provide/use
> historical information, it can simply not implement that part.
I’m also not sure how useful historical datapoint are. I don’t think the use case where someone wants to restore from a seed and get all exchange rates during the time of the payment is something users are looking for.
However, It’s optional.
>
>> If yes, the client should be allowed to decide on which time scale the
>> data should be. (tick, min, hour, day, ...) That goes together with
>> clearly defining the type field (something like low, high, open, close,
>> but without flexibility). Think of a candle-stick chart basically.
>
> How is the current draft insufficient for this?
>
>> Also, pushing may be more appropriate for "current" rates than polling.
>> Then no polling interval is necessary. On the other hand, this adds
>> complexity in other places, e.g., state.
>
> Pushing is what longpolling does.
Agree with Luke. A „real“ push (though I’d say long-polling is the real push, AFAIK it’s also the technique behind Apple’s iOS push channel) would require a complex server setup that complicates many things like load-balancer, mem-caching, etc.
</jonas>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170306/ec223a69/attachment.sig>;