Jeff Garzik [ARCHIVE] on Nostr: š Original date posted:2015-01-19 š Original message:ASN.1 is not nearly as ...
š
Original date posted:2015-01-19
š Original message:ASN.1 is not nearly as flexible when it comes to well-supported libraries,
generators, and the ecosystem that surrounds the actual encoding. You
don't see ASN.1 compilers + language support packages for [all popular
programming languages], as you do with protobufs.
Google engineers were well aware it existed I'm sure. There are wider
considerations beyond the low-level specified format.
Protobufs have their problems and aren't perfect, but ASN.1 ecosystem is
far less developed in the programming ecosystem, far less approachable for
programmers. BIP70 wouldn't have been as easily and widely adopted if
ASN.1 had been chosen.
On Mon, Jan 19, 2015 at 2:19 PM, Matt Whitlock <bip at mattwhitlock.name>
wrote:
> Even if a compact binary encoding is a high priority, there are more
> "standard" choices than Google Protocol Buffers. For example, ASN.1 is a
> very rigorously defined standard that has been around for decades, and
> ASN.1 even has an XML encoding (XER) that is directly convertible to/from
> the binary encoding (BER/DER), given the schema. In practice, I'm mostly
> agnostic about what encoding is actually used in BIP70, and I wouldn't
> fault BIP70 for choosing Google Protocol Buffers, but the very existence of
> Protobuf perplexes me, as it apparently re-solves a problem that was solved
> 40 years ago by ASN.1. It's as though the engineers at Google weren't aware
> that ASN.1 existed.
>
>
> On Monday, 19 January 2015, at 7:07 pm, Richard Brady wrote:
> > Hi Gavin, Mike and co
> >
> > Is there a strong driver behind the choice of Google Protocol Buffers for
> > payment request encoding in BIP-0070?
> >
> > Performance doesn't feel that relevant when you think that:
> > 1. Payment requests are not broadcast, this is a request / response flow,
> > much more akin to a web request.
> > 2. One would be cramming this data into a binary format just so you can
> > then attach it to a no-so-binary format such as HTTP.
> >
> > Some great things about protocols/encodings such as HTTP/JSON/XML are:
> > 1. They are human readable on-the-wire. No Wireshark plugin required,
> > tcpdump or ngrep will do.
> > 2. There are tons of great open source libraries and API for parsing /
> > manipulating / generating.
> > 3. It's really easy to hand-craft a test message for debugging.
> > 4. The standards are much easier to read and write. They don't need to
> > contain code like BIP-0070 currently does and they can contain examples,
> > which BIP70 does not.
> > 5. They are thoroughly specified by independent standards bodies such as
> > the IETF. Gotta love a bit of MUST / SHOULD / MAY in a standard.
> > 6. They're a family ;-)
> >
> > Keen to hear your thoughts on this and very keen to watch the payment
> > protocol grow regardless of encoding choice! My background is SIP / VoIP
> > and I think that could be a fascinating use case for this protocol which
> > I'm hoping to do some work on.
> >
> > Best,
> > Richard
>
>
> ------------------------------------------------------------------------------
> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> http://p.sf.net/sfu/gigenet
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150119/439ccfd3/attachment.html>;
š Original message:ASN.1 is not nearly as flexible when it comes to well-supported libraries,
generators, and the ecosystem that surrounds the actual encoding. You
don't see ASN.1 compilers + language support packages for [all popular
programming languages], as you do with protobufs.
Google engineers were well aware it existed I'm sure. There are wider
considerations beyond the low-level specified format.
Protobufs have their problems and aren't perfect, but ASN.1 ecosystem is
far less developed in the programming ecosystem, far less approachable for
programmers. BIP70 wouldn't have been as easily and widely adopted if
ASN.1 had been chosen.
On Mon, Jan 19, 2015 at 2:19 PM, Matt Whitlock <bip at mattwhitlock.name>
wrote:
> Even if a compact binary encoding is a high priority, there are more
> "standard" choices than Google Protocol Buffers. For example, ASN.1 is a
> very rigorously defined standard that has been around for decades, and
> ASN.1 even has an XML encoding (XER) that is directly convertible to/from
> the binary encoding (BER/DER), given the schema. In practice, I'm mostly
> agnostic about what encoding is actually used in BIP70, and I wouldn't
> fault BIP70 for choosing Google Protocol Buffers, but the very existence of
> Protobuf perplexes me, as it apparently re-solves a problem that was solved
> 40 years ago by ASN.1. It's as though the engineers at Google weren't aware
> that ASN.1 existed.
>
>
> On Monday, 19 January 2015, at 7:07 pm, Richard Brady wrote:
> > Hi Gavin, Mike and co
> >
> > Is there a strong driver behind the choice of Google Protocol Buffers for
> > payment request encoding in BIP-0070?
> >
> > Performance doesn't feel that relevant when you think that:
> > 1. Payment requests are not broadcast, this is a request / response flow,
> > much more akin to a web request.
> > 2. One would be cramming this data into a binary format just so you can
> > then attach it to a no-so-binary format such as HTTP.
> >
> > Some great things about protocols/encodings such as HTTP/JSON/XML are:
> > 1. They are human readable on-the-wire. No Wireshark plugin required,
> > tcpdump or ngrep will do.
> > 2. There are tons of great open source libraries and API for parsing /
> > manipulating / generating.
> > 3. It's really easy to hand-craft a test message for debugging.
> > 4. The standards are much easier to read and write. They don't need to
> > contain code like BIP-0070 currently does and they can contain examples,
> > which BIP70 does not.
> > 5. They are thoroughly specified by independent standards bodies such as
> > the IETF. Gotta love a bit of MUST / SHOULD / MAY in a standard.
> > 6. They're a family ;-)
> >
> > Keen to hear your thoughts on this and very keen to watch the payment
> > protocol grow regardless of encoding choice! My background is SIP / VoIP
> > and I think that could be a fascinating use case for this protocol which
> > I'm hoping to do some work on.
> >
> > Best,
> > Richard
>
>
> ------------------------------------------------------------------------------
> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> http://p.sf.net/sfu/gigenet
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150119/439ccfd3/attachment.html>;