LINUX.ORG.RU

XML это еще актуально для межмашинного обмена?

 


1

1

Добрый день, возникла потребность от собственного формата обмена данными между машинами (небольшие файлы) перейти к чему-то стандартном. Раньше кое-где использовали json ну и protobuf. А что на счет XML это совсем уже устаревшее решение или есть еще плюсы у этой технологии? Посмотрел видео создателя json так он говорит, что дескать «xml - сложно», но на мой взгляд что json что xml



Последнее исправление: da17 (всего исправлений: 1)

Ответ на: комментарий от Legioner

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

Так вам производительность, или простоту разработки?

легко посмотреть внутрь протокола и без всяких понять, что там происходит

Посмотреть – легко, понять – нет.

А текстовый оверхед тривиально устраняется опциональным gzip-ом поверх основного протокола, например как это сделано в HTTP.

Не устраняется. Оверхед там далеко не только в размере, но и в разборе/сериализации текстовой портянки с escape-символами и текстовыми же кейвордами.

Siborgium ★★★★★
()
Ответ на: комментарий от sigurd

Это дискеты то надежнее?

ага, особенно 7.25

Вот перфокарты - самые надежные!

Не секурно же, подлый шпиён с запада на микроплёнку фотоаппаротом сфоткает твои перфокарты и главная государственная тайна утечёт к капиталистам. так что думай что говоришь, первый отдел не дремлет!

anonymous
()

Для межмашинного обмена подойдёт абсолютно любой формат, хоть бинарный. Какая библиотека тебе удобнее ту и бери. Лично я бы взял, конечно, XML.

vtVitus ★★★★★
()
Ответ на: комментарий от Psilocybe

XML - хорошая поддержка в нормальных СУБД. Можно писать запросы как из таблицы.

В нормальный СУБД и json норм. поддерживается https://postgrespro.ru/docs/postgresql/14/datatype-json

https://postgrespro.ru/docs/postgresql/14/functions-json#FUNCTIONS-JSON-PROCESSING

причём даже с индексами. Я его использовал в прототипе - «ваще прапёрся».

vtVitus ★★★★★
()
Последнее исправление: vtVitus (всего исправлений: 1)

между ними нет особой разницы, просто json использовал синтаксисис js, это казалось удобным кому то, а по сути это те же яйца.

ecname
()
Ответ на: комментарий от X512

Данные - это условно предмет сообщения. Метаданные - данные о данных.

С практической точки зрения метаданные часто являются менее значимыми, например. И даже если их нельзя отбросить - это может упрощать работу с данными при просмотре вне программы. (на примере HTML: поле href ссылки важно, но не необходимо для чтения текста)

Увы, как я жаловался, значительное число разработчиков форматов на основе XML (во главе с нашей налоговой) игнорируют этот аспект и хранят данные в атрибутах.

Scondo
()
Ответ на: комментарий от Legioner

Парситься он от gzip быстрее не станет

Скорость парсинга не важна практически никогда. Всё равно твоя сетевая столько не прожуёт.

А потом удивляемся, что софт бешено тормозит на самом современном железе. И кстати, JFYI: gzip-анье на сервере более ресурсоёмко чем ungzip-нье на клиенте, а серверу и без gzip-анья есть чем заняться.

dimgel ★★★★★
()
Ответ на: комментарий от dimgel

У меня ничего не тормозит. ЧЯДНТ? Кроме гзипа есть бротли и другие варианты. Подобрать подходящий можно.

Legioner ★★★★★
()

Все упирается в характер данных для обмена, если там произвольные документы неоднозначной структуры, то имеем смысл XML, если там более менее детерменированные наборы данных аля «RPC/Строка данных/Реестр строк данных» то json будет проще.

TEX ★★★
()
Ответ на: комментарий от Legioner

С невалидным JSON по крайней мере я в природе не встречался.

Можно попробовать скормить Relaxed JSON парсеру, который расслабляться не умеет.

Suigintou ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.