Почему asn1 так не сильно популярен?

Какой вообще смысл делать human readable протокол, если заранее известно, что ни один human читать его не будет?

говори за себя.

вкратце, большую роль играют два фактора: а) асн малоизвестен, и б) асн оверкомпликейтед. как ты понимаешь, эти два фактора связаны.

Взять протокол того же дибаса например. Зачем было изобретать свой протокол, если можно было просто написать asn спеки?

Ну, я думаю, недоученные ПТУшники, которые писали спеки DBus, просто не слышали об ASN.1 С технической стороны - разве в ASN.1 есть интроспекция?

Интереснее, почему существуют Thrift и protobuf. Сам Валкин затруднился ответить :)

разве в ASN.1 есть интроспекция?

Теоретически можно засунуть set в sequence of например. А встроеные типы и в дибасе есть.

С пунктом а согласен. А пункт б - даже не знаю. Неужели в индустрии так много неосиляторов? Всё так плохо?

Смотря где популярен, в sigtran это основа.

Ух ты, интересно! Спасибо. Я вообще отметил, что в современной мобильной связи, и вообще там, где руку приложили „дипломированные инженеры“, только его для передачи и используют. Что как бы намекает.

Сам Валкин

надо ему передать, что его уже с двух больших букв называют =)

Валкин-Сан!

Еще что вспомнилось - LDAP и где то в ssl для сертификатов тоже asn1 используется.

ящетаю что такая запись имени начисто убивает производительность, и если уж соглашаться на некоторые послабления, то сразу записывать

(Сан Валкин)

Может быть сам ASN.1 не так популярен, но кодирование данных в BER/DER довольно распространено. ИМХО, что ASN.1 имеет не очень большую популярность в массах из-за не очень большого количества достойных инструментальных средств для разных языков программирования. Помимо того же Си и Эрланга ничего достойного припомнить не могу. Для Java в своё время достаточно живой библиотеки (на уровне того же libtasn хотя бы, чего уж говорить про Эрланг) не нашёл, пришлось использовать то, что есть в Bounty Castle, но это неудобно, т.к. фактически пришлось повторять всё описание схемы, но в ООП, что нахрен не надо. С pyasn1 то же самое. Хотя с последним можно было на коленке наваять простенький транслятор, но быстрее всё-таки было руками перефигачить.

Да, про это я уже слышал. Про сертификаты очень во многих местах пишут в качестве примеров, а про ldap я отсюда узнал.

Думаю это уже от религии зависит. Можно ещё SELECT Валкин WHERE Валкин IS Сан. Я не спец в sql если что)

Я вообще отметил, что в современной мобильной связи, и вообще там, где руку приложили „дипломированные инженеры“, только его для передачи и используют.

ASN.1 - это телекомовский стандарт. У того же RDP ноги растут из телекома - там ASN.1; то же и с LDAP, и с SNMP.

Кстати, мега круто что в OTP отличный asn1 компайлер есть - erlang крут.

Ну так язык для телекома делали. Было бы странно если бы такой нужной штуки в нём бы не было )

Ну такое, знаешь, походу его делали в первую очередь для потребностей E///, тот же diameter который в LTE дофига, ток не давно появился, да и клиент LDAP тоже не давно сравнительно появился.

А если глянуть по софту который пишется - так вообще, почему то все в веб лезут в erlang. На днях сталкнулся с проблемой что ESL сборки erlang без sctp идут - а всем пофиг, типа хз что это. Вот такой телеком.

он переусложнен.

К тому же - что мне вот в protocol buffers нравится - так это forward compatibility. Т.е. расширение структуры сообщения, а в некоторых случаях даже замена типа - не ломает обратную совместимость. Не знаю как в ASN.1 BER с этим, но подозреваю что никак.

Короче, ASN.1 не нужен. Он сложный и мудацкий.

Protocol buffer удобнее и проще. А для тех, кому нужно одни и те же структуры еще в какой-нибудь JSON засовывать, чтобы скажем, на UI выводить - есть такая штука как piqi: http://piqi.org

Короче, ASN.1 не нужен. Он сложный и мудацкий.

Пришел лавсан и всё прояснил! Спасибо тебе, бро.

ASN.1 предназначен для описания различных нетривиальных протоколов. Популярное — это одноклассники и вконтакт. Там лишние сложности не нужны.

Не знаю как сейчас дело обстоит, но в свое время пришлось отказаться от ASN1 из-за полного отсутствия вменяемого инструмента для декларации структур. + было 2 либы (одна под оффтопик, вторая под *nix) так вот иногда первая могла накодить так, что вторая просто ниосиливала. В результате напилили свой лисапед с варинтами флоатами, который потом легко заменился на протобуфер

К тому же - что мне вот в protocol buffers нравится - так это forward compatibility. Т.е. расширение структуры сообщения, а в некоторых случаях даже замена типа - не ломает обратную совместимость. Не знаю как в ASN.1 BER с этим

Так же.

А что за библиотеки?

под никс не скажу (просто не имел с ней дела), под венду была платная с платным компилятором же. Писали какие-то не то англичане, не то Ирландия. libasn1 тогда еще не было. 2001 год.

К тому же - что мне вот в protocol buffers нравится - так это forward compatibility.

А ты догадайся, откуда это слямзили.

Короче, ASN.1 не нужен.

Не аргумент. Это стандарт, и он оптимален для трансфера структурированной информации.

С технической стороны - разве в ASN.1 есть интроспекция?

Зачем она в asn, который по большей части, реализует кодирование/декодирование. Фишка с оверхедом, в большинстве своем не нужная, легко реализуемая на базе протокола.

Ну, я думаю, недоученные ПТУшники, которые писали спеки DBus, просто не слышали об ASN.1 С технической стороны - разве в ASN.1 есть интроспекция?

Если рассматривать дибас как протокол обмена данными, то интроспекции там тоже нет. Она прекручена отдельным протоколом в стиле «клиент обязан отзываться на такие-то методы, чтобы сообщать о себе всё, что знает».

Ну, я думаю, недоученные ПТУшники, которые писали спеки DBus, просто не слышали об ASN.1

Кстати, вполне вероятно, что так и есть.