plateform)
And since it would take too much time to do that, I end up delegating
parsing and trust verification to a third party service.
2015-01-28 14:32 GMT+01:00 Wladimir laa...@gmail.com:
On Wed, 28 Jan 2015, Nicolas DORIER wrote:
I agree that the use protocol buffer and x509 by BIP70
I agree that the use protocol buffer and x509 by BIP70 is a poor choice.
The choice should have been done to maximize portability, not to maximize
efficiency and flexibility.
What I ended up doing for having a similar codebase on all plateform is to
parse a BIP70 messages with the help of a web
a bit.
Whilst I appreciate if your platform provides a scripting-like API and
nothing low level it might seem easier to use JSON+HTTPS, that isn't the
case for one of the primary design targets.
On Wed, Jan 28, 2015 at 6:04 PM, Nicolas Dorier nicolas.dor...@gmail.com
wrote:
Mike, I am
My point is not that there is a limitation in BIP70. My point is that you
put the burden of certificate verification on developer's shoulder when we
can just leverage built in HTTPS support of the platform.
This make cross plateform dev a nightmare.
Sure I can use a snapshot of moz/apple/msft
For the number of field there is in the spec, I don't consider having a
JSON to schama really worthwhile.
If you fear it is error prone, then we should provide some testing data for
the BIP70. (Which I already did for protobuf, but was rejected, because
deemed no useful thanks to the code
Mike, I am not denying it is impossible to do all of that.
Just that it is not a trivial stuff to do to make it works everywhere, and
I think that it is not a good thing for a client side technology.
BIP70 has its use, and I understand why there is case where it is good to
ship the certs in the
things to speculate
than who gets the biggest gun in the core team.
Please consider my solution,
Nicolas Dorier,
--
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring
7 matches
Mail list logo
