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

json

Смотря для чего.

http://en.wikipedia.org/wiki/Comparison_of_data_serialization_formats

CORBA

Смотря для чего.

Метать наборы данных типа 'параметр:значение' через интернет

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

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

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

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

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

sqlite

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

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

это не слухи http://ru.wikipedia.org/wiki/Protocol_Buffers
и он для хранения данных не используется

ps: http://en.wikipedia.org/wiki/Comparison_of_data_serialization_formats

Да, пожалуй на JSON остановлюсь. Замечательная штука =)

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

А это тут вообще при чем?

Зачет.

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

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

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

гугл - protobuf
где-то слышал, что обладает самой быстрой сериализацией/десериализацей

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

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

А это тут вообще при чем?

а там ктото чтото про хранение сказал и я на всяк случай уточнил

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

yaml

Ага и самым уродским API

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

Чего такого самого уродского в этом API? По-моему вполне удобно и продумано.

Увы так. Но со своей задачей протобуф справляется более, чем просто хорошо.

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

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

Мамма миа!

Глянул примеры — ну и уродец же этот protobuf!

А чего libjson не пользоваться?

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

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

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

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

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

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

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

jni

OMG!

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

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

Json

OMG!

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

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

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

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

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

Самое простое имхо - json.

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

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

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

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

xml ненужно
нужно json

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

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

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

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

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

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

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

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

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/. КорбахейтерыБуферофаги в коментах бугуртят «А судьи кто?!!»

а вы таки libxml2 в руках не держали, раз считаете, что XML тормозен.

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

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

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

Это понятно.

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

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

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