Здравствуйте, landerhigh, Вы писали:
L>Здравствуйте, netch80, Вы писали:
N>>В старых применениях оно может жить ещё хоть вечно, за компанию к упоминавшемуся тут, не к ночи будь сказано, X12, но если ты мне покажешь хоть один пример новой технологии (а не расширения/дополнения существующих), где применён ASN.1, за последние 15 лет, я буду удивлён. По-моему, последним героическим движением в эту сторону было H.323.
L>На ASN.1 основан ISO9506. И хотя сам протокол уже даже окаменелым говном мамонта назвать не получится, внедрение его в энергетике только сейчас пошло полным ходом. См. IEC61850, вторая версия которого по меркам индустрии вышла только сегодня утром после завтрака.
Только подтверждает мою оценку.
L>Насколько широко оно распространено? Ну, индустриальные защитные и контрольные приборы для подстанций уже практически поголовно если не поддерживают его из коробки, то имеют версию или прошивку с этим протоколом, на худой конец адаптер. Скорее всего, многие бытовые электросчетчики тоже скоро будут поддеживать этот протокол, по крайней мере для smart grids.
Здравствуйте, alex_public, Вы писали:
_>Ааа, ну это другой вопрос. ) Вообще я помнится видел в каком-то стандарте требование на уникальность ключей в json. Так что если кто-то не соблюдает, то...
Это не другой вопрос. Это вопрос (см. http://rsdn.ru/forum/flame.comp/6253172.1
Здравствуйте, alex_public, Вы писали:
_>Ну на сайте того же Parabix есть упоминание только о реализации grep в качестве примера их технологии. Понятно, что json парсер даже проще, так что задача вполне выполнима. Но и её кто-то должен сделать, что совсем не тривиально с учётом особенностей данного подхода. Так что подождём ответа Cyberax'а с деталями.
Я просто взял статью о Parabix'е и сделал как там написано. Руками на бумажке выписал все возможные комбинации событий и сделал парсер. Где-то через неделю оно даже заработало.
Статью о Parabix'е кто-то (я?) засылал сюда ещё году так в 2005-м, вот где-то год назад она пригодилась.
Здравствуйте, Sinclair, Вы писали:
_>>Про использование SIMD для текстовых парсеров я действительно был не в курсе, признаю. Правда я вот очень сомневаюсь, что данная хитрая технология применяется в каком-то из так называемых "промышленных" парсеров json. S>Пока — нет. Но те, кто выбирает "три строки на спирите" для таких вещей, гарантированно отрезают себя от передовых достижений.
Так а смысл от них? Даже самый тормозной парсер на Спирите будет работать с достаточной скоростью для разбора гигабитного потока. Причём вполне корректно.
Понятно, что обычно проще использовать библиотеки. Особенно учитывая, что результат разбора JSON в большинстве языков выдаёт обычные стандартные структуры данных. С XML была вечная проблема с тем, что одной библиотеке нужна Dom4J, другой Java DOM, а третей вообще JDOM.
Здравствуйте, Sinclair, Вы писали:
S>Или оба ожидаем, что выигрывает последнее значение. А не так, что я считаю корректным только какое-то одно поведение, а производитель парсера считает, что он волен выбирать поведение по своему вкусу. И вот он в ответ на какую-нибудь жалобу от тех, кому надо коммутировать JSON со скоростью 2GB/sec немножечко меняет внутреннее устройство, и для duplicate keys возврашается первое значение, а не последнее.
По факту, в JSON два правильных поведения: "кто последний тот и папа" или ошибка парсера. Есть ещё разное поведение, если корневой элемент — это массив, а не объект (формально это запрещено, но на практике многие допускают). Ну и как бы всё.
По сложности с XML несравнимо, за счёт чего и рулит.
Здравствуйте, gandjustas, Вы писали:
_>>Ты серьёзно? ))) Ну ок... Я тут уже приводил полную грамматику json'a (правда в синтаксисе спирит'а, но это не суть). Можешь привести аналогичное для xml? ) G>Сам гуглить не умеешь? http://www.boost.org/doc/libs/1_48_0/libs/spirit/example/qi/mini_xml3.cpp G>както вообще не космос.
Это вот только совсем не XML. Разрешения namespace'ов нет, DTD нету, кодировки не поддерживаются, валидация имён неправильная и т.д.
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, Mr.Delphist, Вы писали:
N>>>Тогда и код на C/Delphi/LISP/etc. — бинарь, а не текстовик.
MD>>А где в коде C/Delphi/LISP/etc. используются ссылки на encoding?
N>В Python есть. Но наличие текстового encoding как раз и означает текст.
MD>>Тут речь про другое. Создайте такой Xml-файл: MD>>
MD>>Парсится? Парсится, успешно.
MD>>Откройте этот файлик в FAR и замените "something" на "что-то" и сохраните изменения. Теперь попробуйте распарсить этот якобы Xml любым десериализатором. Скорее всего, получите ошибку типа "Invalid character in the given encoding. Line 2, position 14".
N>Объясни, пожалуйста. Стандартный парсер умирает на utf-8 без схемы?
Просто FAR сохраняет не в UTF-8, а либо в однобайтный CP-1251, либо в двухбайтный UTF-16. Парсер находит несоответствие метаданных и контента и выдаёт честное "не шмогла".
Здравствуйте, Mr.Delphist, Вы писали:
MD>>><?xml version="1.0" encoding="UTF-8"?> MD>>><root value="something" /> MD>>>Откройте этот файлик в FAR и замените "something" на "что-то" и сохраните изменения. Теперь попробуйте распарсить этот якобы Xml любым десериализатором. Скорее всего, получите ошибку типа "Invalid character in the given encoding. Line 2, position 14". N>>Объясни, пожалуйста. Стандартный парсер умирает на utf-8 без схемы? MD>Просто FAR сохраняет не в UTF-8, а либо в однобайтный CP-1251, либо в двухбайтный UTF-16. Парсер находит несоответствие метаданных и контента и выдаёт честное "не шмогла".
Не всё так просто. Если я сделаю такой же эксперимент на своей системе (у меня только юниксы, возьмём для примера Ubuntu), там utf-8. Парсер — expat из Питона (ничего проще не нашёл). Парсер со всеми опциями по умолчанию и на файле в utf-8 без BOM мрёт точно так же. Если поставить BOM и/или сказать при создании парсера, чтобы читал в utf-8 — читается без проблем.
Не думаю, что это их самодеятельность. Скорее, режим работы стандартизован на какой-нибудь тупой дефолт типа iso-8859-1.
Здравствуйте, Cyberax, Вы писали:
C>По факту, в JSON два правильных поведения: "кто последний тот и папа" или ошибка парсера. Есть ещё разное поведение, если корневой элемент — это массив, а не объект (формально это запрещено, но на практике многие допускают). Ну и как бы всё.
Все до сих пор встреченные мной JSON парсеры допускали, что корень — что угодно, включая варианты 3.1415926535 или null.
Думаю, это ориентация на вебовую специфику.
Но это таки не усложняет парсер, по крайней мере, если его явно не усложнять
Здравствуйте, flаt, Вы писали:
F>Оказывается, в SQLite тоже прикрутили JSON не так давно.
Лучше они бы ALTER TABLE докрутили, наконец. Добавить колонку в таблицу — пожалуйста, а дропнуть её — фига с маслом. В качестве work-around предлагается пересоздать таблицу и вкачать в неё старые данные за минусом ненужной колонки
Здравствуйте, Sinclair, Вы писали:
_>>Ааа, ну это другой вопрос. ) Вообще я помнится видел в каком-то стандарте требование на уникальность ключей в json. Так что если кто-то не соблюдает, то... S>Это не другой вопрос. Это вопрос (см. http://rsdn.ru/forum/flame.comp/6253172.1
В обсуждение этого вопроса я бы разделил применение JSON на две совершенно разные области:
1. Хранение информации в рамках одной системы
2. Передача информации между разными системами.
Очевидно, что в первом случае никаких особых проблем быть не может, т.к. для сериализации/десериализации применяется один и тот же движок (который естественно самосогласованный).
Во втором случае (это обычно взаимодействие каких-то веб-сервисов и т.п.) при нечёткой спецификации формата конечно возможны какие-то проблемы. Но это вообще довольно проблемная задача, которую в любом случае отлаживают руками.
Здравствуйте, Cyberax, Вы писали:
_>>Ну на сайте того же Parabix есть упоминание только о реализации grep в качестве примера их технологии. Понятно, что json парсер даже проще, так что задача вполне выполнима. Но и её кто-то должен сделать, что совсем не тривиально с учётом особенностей данного подхода. Так что подождём ответа Cyberax'а с деталями. C>Я просто взял статью о Parabix'е и сделал как там написано. Руками на бумажке выписал все возможные комбинации событий и сделал парсер. Где-то через неделю оно даже заработало.
Здорово, серьёзная работа. Не было желания оформить это в виде публичной библиотеки? )
Здравствуйте, alex_public, Вы писали:
C>>Я просто взял статью о Parabix'е и сделал как там написано. Руками на бумажке выписал все возможные комбинации событий и сделал парсер. Где-то через неделю оно даже заработало. _>Здорово, серьёзная работа. Не было желания оформить это в виде публичной библиотеки? )
Давно хочу, как только одобрит юротдел — попробую открыть.
Здравствуйте, netch80, Вы писали:
L>>На ASN.1 основан ISO9506. И хотя сам протокол уже даже окаменелым говном мамонта назвать не получится, внедрение его в энергетике только сейчас пошло полным ходом. См. IEC61850, вторая версия которого по меркам индустрии вышла только сегодня утром после завтрака.
N>Только подтверждает мою оценку.
Здравствуйте, netch80, Вы писали:
N>LTE это логически такое же продление GSM, H.323 и прочего ISO'шного голоса, даже если переведено на IP. Поэтому я считаю его расширением существующего, а не новым.
Нет. Радио часть очень сильно поменялась. Теперь там есть гибкое выделение радиоресурсов под пользователя, полностью дата-ориентированность без всяких тебе там выделенных полос под голосовой трафик. От GSM и H.323 оно ушло очень далеко. N>Да вот берут, постоянно. Предпочитают изобретать собственные стандарты (bencode, protocol buffers и тому подобное), gzip-овать XML и JSON, лишь бы к ASN.1 не приближаться. Мне это тоже немного непонятно, чисто практические наблюдения.
Потому что задачи примитивные и объёмы трафика небольшие, при этом у них нет требований к ресурсам канала. Не хватает канала? Бросим ещё оптоволокна, больше оптоволокна для передачи XML/JSON., С радиоканалом это не пройдёт, дадут тебе 5 или 1.4 MHz и крутись как хочешь.
Здравствуйте, Cyberax, Вы писали:
_>>Здорово, серьёзная работа. Не было желания оформить это в виде публичной библиотеки? ) C>Давно хочу, как только одобрит юротдел — попробую открыть.
Дома надо эксперементировать
Здравствуйте, Sheridan, Вы писали:
S> _>>Здорово, серьёзная работа. Не было желания оформить это в виде публичной библиотеки? ) S> C>Давно хочу, как только одобрит юротдел — попробую открыть. S> Дома надо эксперементировать
Зачем, если можно на рабочем месте за деньги?
Здравствуйте, Dziman, Вы писали:
S>> _>>Здорово, серьёзная работа. Не было желания оформить это в виде публичной библиотеки? ) S>> C>Давно хочу, как только одобрит юротдел — попробую открыть. S>> Дома надо эксперементировать D>Зачем, если можно на рабочем месте за деньги?
А, ты всего лишь профессионал
Здравствуйте, Sheridan, Вы писали:
S>>> Дома надо эксперементировать D>>Зачем, если можно на рабочем месте за деньги? S>А, ты всего лишь профессионал
Ты всегда все эксперименты ставишь только дома и бесплатно? Завидую. Меня жена давно бы выставила из дому. Ну правда, на кой ей муж, который дома ей предпочитает компьютерные изыскания и из сервантов делает компьютерную технику.
И вообще, ты так говоришь, как будто профессионал — это что-то плохое.
Не было желания оформить это в виде публичной библиотеки? )
