LINUX.ORG.RU

Что нынче модно использовать вместо XML?


0

2

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

P.S. Ходят слухи у гугла есть самопальный бинарный формат.

З.Ы. Забыл уточнить что это нужно для метания текста между программами, а не для хранения данных.

★★★★★

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

Для этого что угодно, json, ini, xml/sxml. Именно через интернет можешь прямо GET-запросами передавать :)

staseg ★★★★★ ()

только asn.1, только хардкор!

ymn ★★★★★ ()

json, yml - в зависимости от задачи

anonymous ()

Если много разнородных данных надо хранить, то лучше всего sqlite или postgres какой-нибудь. Если не очень много — JSON. Если совсем чуть-чуть — самопальный текстовый формат.

Если не нужна переносимость — хоть бинарник (только при переходе, скажем, с 64 на 128 бит или же с остроконечной на тупоконечную архитектуру получишь фигу).

Anon ()

Я в питоне json использую. Но не нравится мне первые две буквы :)

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

Ты бы лучше сказал, зачем тебе это нужно: хранить данные, передавать данные... А то, может, еще и человек их должен легко править/смотреть вручную?

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

А то, может, еще и человек их должен легко править/смотреть вручную?

А если человек должен страдать - то лучше на xml остаться?

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

Вот так и сериализуй - «параметр:значение\n», а знак ':' декорируй как '\:' и '\' как '\\'. Сериализация и десериализация пишется в две строки, и быстрее этого будет только бинарный формат (который тоже делается в две строки).

Так что не понятно, о чем вообще вопрос.

anonymous ()
Ответ на: комментарий от Siado

Да. Если человек должен страдать немного — то бинарник или БД. Если вообще не должен страдать — что-нибудь более простое, чем JSON.

Anon ()
Ответ на: комментарий от ratatosk

Во-первых, он _разный_ в разных языках. Во-вторых, на кой хрен нужны эти сраные геттеры и сеттеры и билдеры (!!!)? Почему нельзя было сделать по-человечески и генерить сразу структуры и сериализаторы, зачем делать такое нагромождение сущностей? А еще у них потоки с счетчиком байтов, который при «переполнении» кидается исключениями.

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

потому что мне нужна одинаковая сериализация/десериализация бинарных данных в бинарный формат из как минимум двух языков (c++, scala)

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

А что, всякие htons'ы не помогают с pragma align?

А еще лучше — sqlite какой-нибудь использовать, где это уже реализовано…

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

А что, всякие htons'ы не помогают с pragma align?

Руками все делать, а потом оборачивать в jni ? Нафиг нафиг! Лучше я 10 минут посношаюсь со страшным гугловым API.

А еще лучше — sqlite какой-нибудь использовать, где это уже реализовано…

Это не лучше, а хуже. Как этот ужас потом в поток отправлять подумал? Ну конечно есть знакомые уникумы, которые в mysql'ные блобы сериализуют и шлют в сеть :)

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

jni

OMG!

Как этот ужас потом в поток отправлять подумал?

А ты о потоке не говорил. А в поток лучше всего таки JSON!

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

OMG!

Вот и я о том же, поэтому protobuf.

А в поток лучше всего таки JSON!

Бинарные данные, поэтому не лучше.

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

В структуре было бы не так удобно представлять поля, у которых значение не выставлено. Зато есть рефлексия, если нужен тот же JSON, можно автоматически туда-сюда переводить с её помощью. Вобщем, я проблем не испытал.

Кроме С++ трогал только стороннее Haskell API, но там большая часть ужаса была следствием не самой удобной работой со структурами в языке.

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

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

В thrift это решено с помощью полей-флагов, что гораздо удобней.

Кроме С++ трогал только стороннее

java попробуй, там API совсем другой, прикрутили эти идиотские билдеры, например, я не могу десериализовать структуру, изменить поле и обратно сериализовать, надо устраивать свистопляску с билдером и копированием _всех_ полей

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

JSON это такой же XML, только в профиль.

Алсо, формат данных тормозить не может.

anonymous ()
Ответ на: комментарий от Skolotovich

и он для хранения данных не используется

С чего это? В самом гугле протобуф в том числе используют для хранения в Bigtable.

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

Уточнил ты неправильно, вполне используется и для хранения в том числе.

С чего это? В самом гугле протобуф в том числе используют для хранения в Bigtable.

промашка вышла (:
я его видел только как для сериализации при передачи чегото кудато

Skolotovich ★★★ ()

Тут и думать не о чем. Thrift.

anonymous ()
Ответ на: комментарий от Reset

Cорта РПЦмиддлвари :) Про эти самые буфера один из авторов CORBA, Стив Виноски, писал буквально следующее: «Еще одно RPC. Серьезный бизнес» (с) http://steve.vinoski.net/blog/2008/07/11/protocol-buffers-no-big-deal/ и следующее: http://steve.vinoski.net/blog/2008/07/13/protocol-buffers-leaky-rpc/. КорбахейтерыБуферофаги в коментах бугуртят «А судьи кто?!!»

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

XML по определению, фундаментально тормозной. Теоретический предел скорости xml-сериализации и десериализации намного ниже чем у даже самого тупого бинарного формата.

anonymous ()
Ответ на: комментарий от actics

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

json от xml ничем не отличается, те же самые проблемы с теоретическим пределом скорости десериализации.

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

json от xml ничем не отличается, те же самые проблемы с теоретическим пределом скорости десериализации.

А практический предел скорости десериализации у тебя был?

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

Не распарсил. Что понимаешь под практическим пределом?

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