3 ms·

I recommend ASN.1 PER over any of the myriad byte-aligned no-schema formats that waste bits on ranges of values and entire types you aren't sending. But this is

I recommend ASN.1 PER over any of the myriad byte-aligned no-schema formats that waste bits on ranges of values and entire types you aren't sending. But this is better than some other formats I've seen.

andrewcooke 17y ago
isn't ASN.1 proprietary? i wanted to implement it once and found i had to pay someone for specs. is that wrong? if not, i think many people would prefer something more open (more implementations; less likely to die from lack of support) [edit: sorry, i am talking rubbish here. they are all linked from here, for example: http://en.wikipedia.org/wiki/Abstract_Syntax_Notation_One http://en.wikipedia.org/wiki/Abstract_Syntax_Notation_One i have no idea why i thought they were closed. has the ITU policy changed recently?]
- alavrik 17y ago
  The specs were definitely closed last time when I checked (about 6 months ago). Still don't think this old telecom technology is superior compared to modern serialization tools like Protocol Buffers.
  - viraptor 17y ago
    old and modern do not mean anything in programming world. C is old - doesn't mean it's better or worse than modern languages. Could you rephrase it in terms of features we can actually compare? I prefer to rely on "old telecom technology" many times, since it's meant to be as close as possible to 100% reliability (telecom being the keyword, not old).
    - alavrik 17y ago
      I agree that old and modern are not very appropriate terms when comparing technologies. However I didn't mean to express an objective statement in my comment.
  - prodigal_erik 17y ago
    If you send a thousand key/value pairs, protocol buffers waste sixteen thousand bits redundantly expressing the type and tag of each key and value, when the recipient already knows they're all the same. (They revved their format to special-case this but only for a sequence of numbers, not any other type you can construct.) PER is the only format I've seen that uses the schema to decide how much information the recipient actually needs to decode the message and just sends that, rather than adding pure overhead just in case a recipient has no idea what's going on yet is somehow supposed to do something useful with the message.
    - alavrik 17y ago
      It is true that Protocol Buffers are not optimized for low-mem systems. On the other hand, for preserving bandwidth and storage one can use lightweight compression algorithms on top of general-purpose serialization library. (This is the approach that Google ended up using, AFAIK.) I think such approach is more flexible than making explicit assumptions on how much data is actually carried in integers.

andrewcooke 17y ago

isn't ASN.1 proprietary? i wanted to implement it once and found i had to pay someone for specs. is that wrong? if not, i think many people would prefer something more open (more implementations; less likely to die from lack of support) [edit: sorry, i am talking rubbish here. they are all linked from here, for example: http://en.wikipedia.org/wiki/Abstract_Syntax_Notation_One http://en.wikipedia.org/wiki/Abstract_Syntax_Notation_One i have no idea why i thought they were closed. has the ITU policy changed recently?]

alavrik 17y ago
The specs were definitely closed last time when I checked (about 6 months ago). Still don't think this old telecom technology is superior compared to modern serialization tools like Protocol Buffers.
- viraptor 17y ago
  old and modern do not mean anything in programming world. C is old - doesn't mean it's better or worse than modern languages. Could you rephrase it in terms of features we can actually compare? I prefer to rely on "old telecom technology" many times, since it's meant to be as close as possible to 100% reliability (telecom being the keyword, not old).
  - alavrik 17y ago
    I agree that old and modern are not very appropriate terms when comparing technologies. However I didn't mean to express an objective statement in my comment.
- prodigal_erik 17y ago
  If you send a thousand key/value pairs, protocol buffers waste sixteen thousand bits redundantly expressing the type and tag of each key and value, when the recipient already knows they're all the same. (They revved their format to special-case this but only for a sequence of numbers, not any other type you can construct.) PER is the only format I've seen that uses the schema to decide how much information the recipient actually needs to decode the message and just sends that, rather than adding pure overhead just in case a recipient has no idea what's going on yet is somehow supposed to do something useful with the message.
  - alavrik 17y ago
    It is true that Protocol Buffers are not optimized for low-mem systems. On the other hand, for preserving bandwidth and storage one can use lightweight compression algorithms on top of general-purpose serialization library. (This is the approach that Google ended up using, AFAIK.) I think such approach is more flexible than making explicit assumptions on how much data is actually carried in integers.