Comments 51
UFO just landed and posted this here
А мобильные устройства (браузеры в мобильных устройствах) поддерживают сжатие трафика? Если да, то тогда возникает вопрос: сколько это съедает процессорного времени. А в мобильных устройствах железо не очень мощное:)
Собственно по этому от сжимания нам пришлось отказаться (
Точнее, этим менеджер проекта мотивировал зарезание такой фичи.
На сколько он был прав, сложно сказать…
Точнее, этим менеджер проекта мотивировал зарезание такой фичи.
На сколько он был прав, сложно сказать…
UFO just landed and posted this here
Авторы отталкиваются от проблем RIA приложений. Как будет выполняться на PDA «богатое» приложение, если PDA не может переварить большой поток данных gzip?
Впрочем, если взять какой-нибудь ExtJS и сравнить его размеры с данными, которые он крутит в среднестатистических реальных приложениях, то проблема мне кажется немного надуманной.
Впрочем, если взять какой-нибудь ExtJS и сравнить его размеры с данными, которые он крутит в среднестатистических реальных приложениях, то проблема мне кажется немного надуманной.
UFO just landed and posted this here
Вы собираетесь заставить пользователей читать вместо подготовленного документа данные в формате JSON? Мое мнение JSON и XML это формат обмена данными между программами (или модулями программы). Читаемость примерно везде одинакова, выбор формата передачи данных зависит только от предпочтений программиста и имеющихся готовых модулей.
Да при некотором понимании формата +) читаемость одинаковая, ну или сопоставимая.
Выбор зависит не только от мнения программиста (
к сожалению, или к счастью,
есть еще куча заинтересованных сторон,
которые накладывают свои ограничения.
Хотя я с вами согласен.
Готовность модулей, библиотек и опыт — главные факторы.
Выбор зависит не только от мнения программиста (
к сожалению, или к счастью,
есть еще куча заинтересованных сторон,
которые накладывают свои ограничения.
Хотя я с вами согласен.
Готовность модулей, библиотек и опыт — главные факторы.
>А еще, JSON куда более читабильнее и полезная информация воспринимается куда проще
При чем здесь читабельность???
GIF, JPG и PNG вообще нечитабельны. Но оченьудобны для передачи картинок. Хотя конечно можно передать их в виде json(xml) и отрисовать попиксельно.
При чем здесь читабельность???
GIF, JPG и PNG вообще нечитабельны. Но оченьудобны для передачи картинок. Хотя конечно можно передать их в виде json(xml) и отрисовать попиксельно.
XML это вообще-то EXtensible Markup Language. Язык разметки, а не «универсальный способ записи древовидных структур». Прозреваю заговор маркетологов и интырпрайз-программистов.
И почему бы не использовать S-выражения? Они проще для разбора компьютером и проще для чтения человеком, чем XML.
Ваш пример можно записать так:
(ru.golodnyj.lection.json.Client [(userName «name») (verified true) (userId 5)])
Главное — не запутаться в скобочках. ;)
И почему бы не использовать S-выражения? Они проще для разбора компьютером и проще для чтения человеком, чем XML.
Ваш пример можно записать так:
(ru.golodnyj.lection.json.Client [(userName «name») (verified true) (userId 5)])
Главное — не запутаться в скобочках. ;)
UFO just landed and posted this here
Целиком и полностью присоединяюсь к точке зрения, что использовать какую-нибудь технологию следует только понимая для чего она предназначена.
JSON интересная мысль, рекомендую послушать рассказ автора про то, как «я стал стандартом» :)
Ссылка была где-то на yahoo developers. И вообще, Даг очень импозантный и грамотный пипл.
Кстати, по поводу JSON'а в народу ходят мысли, что неплохо было бы его сделать в формате multiple documents in file, т.е. по сути вычитывать тривиальный список JSON объектов (одна строка — один документ), но с возможностью зкомментить (!) какой-либо из них.
Если не описаться сильно на Javascript, то в этой ситуации неплохо выглядит YAML, он даже покомпактнее будет.
Если говорить о бинарных сериализаторах, то можно взглянуть на Hessian.
А когда действительно нужна максимальная скорость, то видимо google protobuf тут вне конкуренции.
JSON интересная мысль, рекомендую послушать рассказ автора про то, как «я стал стандартом» :)
Ссылка была где-то на yahoo developers. И вообще, Даг очень импозантный и грамотный пипл.
Кстати, по поводу JSON'а в народу ходят мысли, что неплохо было бы его сделать в формате multiple documents in file, т.е. по сути вычитывать тривиальный список JSON объектов (одна строка — один документ), но с возможностью зкомментить (!) какой-либо из них.
Если не описаться сильно на Javascript, то в этой ситуации неплохо выглядит YAML, он даже покомпактнее будет.
Если говорить о бинарных сериализаторах, то можно взглянуть на Hessian.
А когда действительно нужна максимальная скорость, то видимо google protobuf тут вне конкуренции.
Сравнивать «JSON против XML» бессмысленно.
Попробуйте через JSON передать информацию с переносом строки… JSON предназначен только для обмена небольшими данными. Если данных много и они разного формата, безусловно XML лучше.
Попробуйте через JSON передать информацию с переносом строки… JSON предназначен только для обмена небольшими данными. Если данных много и они разного формата, безусловно XML лучше.
UFO just landed and posted this here
Попробуйте передать через JSON например статью, где есть множество переносов строк.
У json'a нет аналога cdata тега в xml!
Но это не мешает передавать многострочные данные:
RFC4627, пункт 2 приводит примеры записи "%x..", которой можно передавать коды символов. А в 2.1 примеры строк в таком формате (для очень специфичных случаев): "%x66.61.6c.73.65".
Так что всё возможно.
RFC4627, пункт 2 приводит примеры записи "%x..", которой можно передавать коды символов. А в 2.1 примеры строк в таком формате (для очень специфичных случаев): "%x66.61.6c.73.65".
Так что всё возможно.
Забыл сразу написать, извиняюсь. Еще же и unicode-вариант записи символов: \u005C к примеру.
ужас изврат какой О_о
Заменить один символ \n на его символьный код, имхо удобнее и проще, чем городить огород с <![CDATA[… ]]>.
Сейчас не идет речь про передачу исключительно бинарных данных.
Сейчас не идет речь про передачу исключительно бинарных данных.
нет CDATA же как раз нужна для передачи информации не предназначеной для парсинга. Например передать другой xml внутри. Мне как то нужно было передать сгенеренный HTML, к сожалению json'ом его непредать.
{
data: "ссылка"
}
в чём трудности?
data: "ссылка"
}
в чём трудности?
Опять же в S-выражениях элементарно получается:
(my-doc (quote (another-doc (foo bar))))
Или для тех, кому в лом писать quote:
(my-doc '(another-doc (foo bar)))
(my-doc (quote (another-doc (foo bar))))
Или для тех, кому в лом писать quote:
(my-doc '(another-doc (foo bar)))
Про LISP (а это он в принципе и есть) ничего плохого и не скажу, удобная в своей сфере вещь. Но сейчас же речь, как понимаю, о передаче многострочных текстовых данных.
Timmm назвал проблему: вложить документ в документ. В лиспе это делается просто, что я и показал.
Понятное дело, что парсить придется в любом случае: JSON/XML/S-exprs. Нагрузки тоже разные. Но тем не менее, S-exprs являются достойной альтернативой в ряде случаев.
Понятное дело, что парсить придется в любом случае: JSON/XML/S-exprs. Нагрузки тоже разные. Но тем не менее, S-exprs являются достойной альтернативой в ряде случаев.
UFO just landed and posted this here
Несогласен. Я разрабатывал мини протокол обмена сообщениями. Ответ на запрос, xml данные. Если произошла ошибка отображаем ее особым образом. Или если ошибки не произошло отобразить результат запроса (сгенеренный html). По моему не очень на костыль похоже?
у каждого формата есть свои плюсы и как говорили выше — да здравствует компрессия! (которую, кстати, можно отключать для некоторых браузером через htaccess используя подмену файлов)
так же если вы затрудняетесь в выборе «это сюда, а то туда» — сделайте 2 адаптера JSON и XML и используйте где надо ;)
так же если вы затрудняетесь в выборе «это сюда, а то туда» — сделайте 2 адаптера JSON и XML и используйте где надо ;)
может кто знает, а Safari в яблофоне поддерживает сжатие?
>XStream фреймворк
Зачем вы обозвали эту замечательную библиотеку таким плохим словом?
Зачем вы обозвали эту замечательную библиотеку таким плохим словом?
а еще есть YAML, который еще более читаемый, чем json
Я соглашусь с вами, если вы предоставите стандартизированый способ превратить ваше:
json 96:
{«ru.golodnyj.lection.json.Client»: {
«userName»: «name»,
«verified»: true,
«userId»: 5
}}
скажем в:
{«ru.golodnyj.lection.json.Client»: {
«ClientName»: {«Isverified»: true, «userId»: 5}
}}
или скажем в:
ClientName
Name
…
И имея массив из Client находить всех валидных.
В отличии от JSON, XML это позволяет.
json 96:
{«ru.golodnyj.lection.json.Client»: {
«userName»: «name»,
«verified»: true,
«userId»: 5
}}
скажем в:
{«ru.golodnyj.lection.json.Client»: {
«ClientName»: {«Isverified»: true, «userId»: 5}
}}
или скажем в:
ClientName
Name
…
И имея массив из Client находить всех валидных.
В отличии от JSON, XML это позволяет.
Забавно читать такой набор передергиваний.
Т.е. 200 записей в JSON записаных в одну строчку читаются лучше?
или вот тут
Ого, фундаментально непоправимый — какое громкое утверждение, вы такой гуру что разбираетесь в фундаментальной поправимости… круто круто, жаль что первым же комментарием вам показали как очень легко поправить вашу фундаментальную непоправимость.
Слишком много пафоса.
И выводы тоже —
Можно сделать и обратный вывод. Если смотреть с такой мелочной колокольни то да, действительно для вас слишком сложно использовать для решения мелких проблем. И конечно же вам XML непригоден
Жаль, что вы не упомянули ни одной проблемы которая действительно достойна — например сложное иерархическое дерево объектов, которое на вашем jsone перегрузит javascript движок своей вложенностью, а навигация по такой структуре с for в каждой вложенности — легко превысит ресурсоемкость Xpath выражения.
Ну а красота преобразования структуры на jsone в другую — вообще вызовет каталепсию у любого, кто попытается прочитать этот код. Более того я уверен что определенные сложные преобразования на яваскрипте вообще невозможно будет реализовать (по крайней мере в разумные сроки и вменяемыми алгоритмами)
А XSLT преобразования того же самого займут 10-15 строк, ну максимум 2 страницы чистого и легкочитабельного xslt
В общем учите инструменты и их предназначение, а не рассказывайте о найденных вами «фундаментальных недостатках» в технологиях, о которых вы имеете довольно-таки странное представление.
Все вышесказанное — ИМХО. Не буду писать «не хотел обидеть» потому что это неправда. Хотел показать как бессмысленна логика автора и какие удивительные выводы способен сделать человек в погоне за кармой.
И тут возникает первое сомнение: а вот если взять небольшое дерево, узлов на двести и сохранить в виде XML, так ли будет просто его прочитать. Человеку без специального редактора с подстветкой уже практически нереально читать такие файлы (особенно, если они записаны в одну строчку без переносов и табуляций). С этим утверждением сложно не согласиться.
Таким образом, следует откинуть человекочитаемость формата как преимущество и рассматривать XML прежде всего как средство коммуникаций между сервисими, программами или платформами, этакое платформонезависимое средство общения систем.
Т.е. 200 записей в JSON записаных в одну строчку читаются лучше?
или вот тут
Последний из камней сомнений, самый легкий и, в тоже время, фундаментально непоправимый, связан с объемом передаваемых данных, то есть объемом генерируемого трафика
Ого, фундаментально непоправимый — какое громкое утверждение, вы такой гуру что разбираетесь в фундаментальной поправимости… круто круто, жаль что первым же комментарием вам показали как очень легко поправить вашу фундаментальную непоправимость.
Слишком много пафоса.
И выводы тоже —
Можно сделать вывод, что сложность использования XML превышает сложность тех проблем, которые эта технология решает
Можно сделать и обратный вывод. Если смотреть с такой мелочной колокольни то да, действительно для вас слишком сложно использовать для решения мелких проблем. И конечно же вам XML непригоден
Жаль, что вы не упомянули ни одной проблемы которая действительно достойна — например сложное иерархическое дерево объектов, которое на вашем jsone перегрузит javascript движок своей вложенностью, а навигация по такой структуре с for в каждой вложенности — легко превысит ресурсоемкость Xpath выражения.
Ну а красота преобразования структуры на jsone в другую — вообще вызовет каталепсию у любого, кто попытается прочитать этот код. Более того я уверен что определенные сложные преобразования на яваскрипте вообще невозможно будет реализовать (по крайней мере в разумные сроки и вменяемыми алгоритмами)
А XSLT преобразования того же самого займут 10-15 строк, ну максимум 2 страницы чистого и легкочитабельного xslt
В общем учите инструменты и их предназначение, а не рассказывайте о найденных вами «фундаментальных недостатках» в технологиях, о которых вы имеете довольно-таки странное представление.
Все вышесказанное — ИМХО. Не буду писать «не хотел обидеть» потому что это неправда. Хотел показать как бессмысленна логика автора и какие удивительные выводы способен сделать человек в погоне за кармой.
О, если забавно читать такой набор передергиваний то цель свою статья достигла, легкое утреннее чтиво для тех кто умеет читать между строк. Что касается читаемости JSON, то я вроде нигде не говорил о легкости чтения этого формата +) При прочих равных, громкое утверждение является верным, а что касается комментария, вам следует читать ветку целиком.
Теперь перейдем к разбору содержательной части вашего комментария:
Достойная проблема с передачей сложного иерархического дерева в RIA (надеюсь, введение то вы прочитали), на мой взгляд, является проблемой дизайна. Другими словами, если вы знаете о том что поле заминировано — нефиг по нему голышом шастать.
Относительно преобразования JSON структуры в другую JSON структуру, хочу заметить: следует подумать, а с какой целью необходимо выполнение такого странного действа!? Данные, когда приходят на сторону их потребителя должны быть чистыми, вы же не едите вкусный шоколад с совершенно невкусной упаковкой и вам наверняка не прийдет в голову развернуть упаковку с целью переложить шоколад в другую упаковку.
Ваше ИМХО было услышано.
П.С. Что качается кармы:
Теперь перейдем к разбору содержательной части вашего комментария:
Достойная проблема с передачей сложного иерархического дерева в RIA (надеюсь, введение то вы прочитали), на мой взгляд, является проблемой дизайна. Другими словами, если вы знаете о том что поле заминировано — нефиг по нему голышом шастать.
Относительно преобразования JSON структуры в другую JSON структуру, хочу заметить: следует подумать, а с какой целью необходимо выполнение такого странного действа!? Данные, когда приходят на сторону их потребителя должны быть чистыми, вы же не едите вкусный шоколад с совершенно невкусной упаковкой и вам наверняка не прийдет в голову развернуть упаковку с целью переложить шоколад в другую упаковку.
Ваше ИМХО было услышано.
П.С. Что качается кармы:
— Я не понимаю, как вы, швейцарцы, можете сражаться за деньги. Вот мы, французы, сражаемся только ради чести и славы.Это к тому, что каждый судит по себе +)
— Просто каждый воюет за то, чего ему не хватает.
Sign up to leave a comment.
JSON против XML и немного рефакторинга