Protobuf, JSON

hint: s-expressions

В каких задачах?

JSON, S-exp

YAML

>вы используете?

А, стоп. Использую я XML :)

> JSON, S-exp, YAML

Для них есть схемы, валидация?

Альтернатив XML'ю нет.

html

x-expression

Схема по крайней мере у джейсона есть

База данных.

А запросы с клиент-сайда идут сразу к БД? Круто, два года такое хотел. Вот только как ограничивать доступ к БД в таком случае?

OMG

Для чего? Для конфигов? Для передачи данных? Для их хранения?

А что такого? Мне нравится идея, что все веб-приложение написано на js без сервер-сайда.

> Схема по крайней мере у джейсона есть

Посмотрел я пример схемы... ужоснах. DTD проще.

Удобно сделать сложные трансформации на сервер-сайде на нормальномя ЯП, а не на сраном PL/SQL или подобном. Тем более часто есть интеграции с большим количеством систем нужно много кода на сервере

Я и не предлагал серебряную пулю. Нередко веб-приложение является всего лишь простеньким фронтендом к БД (кстати, я имел ввиду нечто вроде mongodb, которое сразу в json'е отдает данные).

А кто тебе сказал, что там вообще есть клиент-сайд?

Боженька.

Плюсую YAML

plaintext в .cfg

<hardcore_mode=«on»>MathML</hardcore_mode>

зависит от задачи, иногда альтернатив нет

а вообще - yaml

А альтернатива чего именно?

А то области применения разные… Если разметка, то альтернатив нет. Если конфиги хранить, то JSON или ini вполне подойдут.

<вброс>А YAML — это вообще какое-то не читаемое говно!</вброс>

> <вброс>А YAML — это вообще какое-то не читаемое говно!</вброс>

Капитан?

> <вброс>А YAML — это вообще какое-то не читаемое говно!</вброс>

Поприятней xml'а будет.

+1

И.О.

Поприятней xml'а будет.

Конечно, конечно… Вот пример из педивикии:

<event name="PRIVMSG">
 <method name="newUri" regex="^http://.*" />
 <method name="deleteUri" regex="^delete.*" />
 <method name="randomUri" regex="^random.*" /> 
</event>

event: PRIVMSG
methods:
  - name: newUri
    regexp: '^http://.*'
  - name: deleteUri
    regexp: '^delete.*'
  - name: randomUri
    regexp: '^random.*'

В случае XML отдельные блоки сразу вычленяются благодаря скобочкам, а вот как парсить твой ямль ХЗ.

sqlite || json
Питоновский модули иногда - как альтернатива json.

а вот как парсить твой ямль ХЗ.

Спроси у лисперов.

На самом деле это всего лишь вопрос привычки.

Лорчую s-exp.

сериализация

последний срач про xml занял ~30 страниц

JSON
Написал на java для него неделю назад библиотечку парсер комбинаторов и генераторов.

>Написал на java для него неделю назад библиотечку парсер комбинаторов и генераторов.
в последнее время ЛОР становится все смешнее.

По сабжу:
лично я - ничего кроме xml для кроссплатформенной передачи данных не вижу. Некоторые мои знакомые используют JSON - им нравится. Я немного тоже попробовал, но отсутствие валидации и плохая читабельность перевысили более высокую скорость маршаллинга/демаршаллинга.

Ну а для конфигов где возможно - аннотациии, где невозможно - ну только XML.

На сегодня считаю XML одним из столпов языков хранения/передачи данных.

Уже одна автогенерация классов из xsd со всеми необходимыми аннотациями многого стоит.

> в последнее время ЛОР становится все смешнее

Что смешного?

плохая читабельность

У XML она лучше? Ты тролль что ли?

Уже одна автогенерация классов из xsd со всеми необходимыми аннотациями многого стоит.

Так говоришь, как будто что-то эдакое. Тулзы типа xjc пишутся за неделю.

>У XML она лучше? Ты тролль что ли?
внезапно да. Мне намного прочще читать xml, чем JSON. Может, дело привычки, не знаю.

Так говоришь, как будто что-то эдакое. Тулзы типа xjc пишутся за неделю.

пока такая тулза одна и аналогов я не знаю даже в других языках.

> пока такая тулза одна и аналогов я не знаю даже в других языках

Для Java есть XMLBeans. Для Scala есть scalaxb. Это я ещё даже не гуглил.

Для С++ есть CodeSynthesis XSD. PyXSD для Python. Ещё за тебя погуглить?

>> плохая читабельность

У XML она лучше? Ты тролль что ли?

Кстати, у XML с разумной схемой читаемость лучше, чем у любого JSON.

>Тулзы типа xjc пишутся за неделю

И для JSONа такие тулзы есть?

А что плохо в XML? Парсится нормально, наверное под любой ЯП есть своя приблуда или встроенный функционал для обработки.

> Кстати, у XML с разумной схемой читаемость лучше, чем у любого JSON.

XML более раздут, т.е. для передачи той же информации, как правило, требуется больше текста. Это, в общем случае, читабельности не способствует.

>> Кстати, у XML с разумной схемой читаемость лучше, чем у любого JSON.

XML более раздут, т.е. для передачи той же информации, как правило, требуется больше текста.

Поэтому я и сказал «для разумной схемы». <elt attr1=foo attr2=bar/> как минимум не хуже {«elt»: { «attr1»: «foo», «attr2»: «bar» }}.

> И для JSONа такие тулзы есть?

Пёс его знает. Мне пока не надо, т.к. Json-схемы я не использую. Но написать, думаю, не проблема.

У меня сейчас данные простые по структуре и большие по объёму. Так что использую сейчас парсер комбинаторы поверх потокового парсера и потоковый же генератор.

> Поэтому я и сказал «для разумной схемы». <elt attr1=foo attr2=bar/> как минимум не хуже {«elt»: { «attr1»: «foo», «attr2»: «bar» }}.

Это всё так чудненько выглядит, пока у тебя простые текстовые атрибуты. А давай attr1 будет составным, а attr2 - массивом.

Это всё так чудненько выглядит, пока у тебя простые текстовые атрибуты.

Ну то есть как минимум иногда XML выглядит нормально.

А давай attr1 будет составным, а attr2 - массивом.

Давай.

<elt>
   <attr1 subattr1=foo subattr2=bar/>
   <attr2>0 1 2 3 4 5 6 7</attr2>
</elt>

{ "elt": { "attr1": { "subattr": "foo", "subattr2": "bar" },
           "attr2": [0 1 2 3 4 5 6 7]}}

Разница в читабельности уменьшилась, но она всё равно в пользу XML.