If you use 0mq, I think pub/sub will be PRed soon. tx-notify calls a process. You can make that whatever's convenient.

As for polling, get_bulk_transfers or the newer get_transfers are useful.

Twister915: it's also possible to generate addresses and use a wallet in a client-side web app which polls a daemon to notify of new txs

using WebAssembly. same idea as JNI, but packaged for the web

that much is already implemented in the monero-javascript project

Hey guys, I finally got some time to work on the epee json-serialization changes we discussed in the past, what I could do is to replace the portable storage parts (those linked to the KV_SERIALIZE macro) used to serialize json structures with new functions that use rapidjson instead, I want to maintain the abstraction so the introduced changes

will only affect epee. I do not intend to change the binary serialization parts, these will remain the same. This will produce some code churn but with the benefit of improving runtime speed and using a maintained library. Do you think this will get accepted?

bysnack: depends on how much churn and how much speedup.

rbrunner: are you around on a relay ?

xiphon: are you ok with 6409 now ?

moneromooo: will have a look in a moment

ty

vtnerd: would you be okay with addressing to 6451 related comments in a separate PR?

I originally did the lexical cast thing IIRC. I did not know about std::to_string at the time :)

I thought a separate PR that addresses all the points for all the code would be better than just part of the code

not sure if that makes sense lol

Sure.

sarang: your opinion? do you want to change the lexical cast stuff or leave it for a different PR?

luigi1111: Snipa: merge list paste.debian.net/hidden/b57d0f42

Thanks!

I don't have a particular opinion on this

I assume this is partly related to the BP PR?

I can change that PR easily if needed

Don't change it here, it's unrelated.

ok