Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, maq, Вы писали:

maq>>Если это будет так интересно кто победит в выборе представления бинарных данных, схема младший байт первым (MS, Linux) или старший первым (IBM/Aix, Sun/Solaris, MacOS)

AVK>При чем тут операционные системы? Порядок следования байт в слове определяется процессором.

Операционные системы полагаются на порядок слов и зависят от него.
К примеру Windows хоть и работает на Alpha, но только в режиме младший первым.
Хотя есть например Solaris который на родной платформе работает старший первым, на x86 наоборот. Но мне кажется что это скорее исключение.

Здравствуйте, vladserge, Вы писали:

V>Здравствуйте, Сан Саныч, Вы писали:


V>>>XML как "крутого" средства обмена данными.
V>>>хранения данных .DBF

СС>>XML удобен когда у тебя существует один клиент и несколько источников(зачастую разработынных третьеми производителями), поставляющие данные в различных форматах...


V>XML — на безптичьи ж.. соловей. Вот и не поняно почему нельзя было сделать и предложить нечто более продуманое.
V>Почему цифры нельзя было представлять в бинарном виде? Почему?

V>Ведь строковое 2 147 483 647 можно передать с помощью 4 byte вместо 10.

ага если бы еще и HTML в бинарном формате был — странички моментом загружались
а JavaScript сразу в байт-кодах...
а Web дизайнер был бы крут как программер на asme

V>А про повторяющиеся по всему файлу теги( порой совершенно кигантской длинны) ....... молчу.
Вот например есть такой стандарт RTF, он очень cильно проигрывает по размеру тому же .doc ,
и внутри много повторяющихся элементов. Зато что бы сделать экспорт какого — нить отчета
в rtf, много сил не надо, а попробуй сохрани в doc !

Вообще есть уже такой протокол -IIOP называется (CORBA), компактный до жути
и DCOM из той же оперы... вот только сложно очень с ними , брокеры нужны всякие,
а они не под все платформы есть. Ведь в чем прелесть XML — есть у тебя библиотека для него
— ок сфрмировал XML через объекты, нет — собрал из строчек. а когда разобрать надо , то даже без парсера,
если знаешь заранее структуру, данные можно вытащить. Переслал по http — вот тебе уже и SOAP


а если тормроза начинаются то это не XML виноват, скорее это ошибка проектирования.
для больших объемов(>1мб) XML мало подходит.

Ведь есть же DIME например, почему не писать данные туда ?

или сделать обмен через CORBA у нее самый маленький траффик.

Здравствуйте, Denis_TST, Вы писали:

D_T>Здравствуйте, vladserge, Вы писали:

V>>Здравствуйте, Сан Саныч, Вы писали:


V>>>>XML как "крутого" средства обмена данными.
V>>>>хранения данных .DBF

СС>>>XML удобен когда у тебя существует один клиент и несколько источников(зачастую разработынных третьеми производителями), поставляющие данные в различных форматах...


V>>XML — на безптичьи ж.. соловей. Вот и не поняно почему нельзя было сделать и предложить нечто более продуманое.
V>>Почему цифры нельзя было представлять в бинарном виде? Почему?

V>>Ведь строковое 2 147 483 647 можно передать с помощью 4 byte вместо 10.

D_T>ага если бы еще и HTML в бинарном формате был — странички моментом загружались
D_T>а JavaScript сразу в байт-кодах...
D_T>а Web дизайнер был бы крут как программер на asme

Утверждаю HTTP — древний, убогий аннохранизм который должен отмереть. История и логика развития показывает все начинаясь небинарным, в итоге таковым становится. DBF > Access, DXF(ASCII) > DXF(binary)...Все мне знакомые Web дизайнеры всегда используют для создания страниц специализированный инструментарий, КРАЙНЕ редко для редактирования используется Notepad.И логика развития — все больше сайтов генерят страницы на лету, чтение и редактирование сгенереного с помощью Notepad — занятие бесперспективное. Машине гараздо проще работать с бинарным форматом ,а мне как програмисту написавшему не один парсер, нужна только спецификация.


V>>А про повторяющиеся по всему файлу теги( порой совершенно кигантской длинны) ....... молчу.
D_T>Вот например есть такой стандарт RTF, он очень cильно проигрывает по размеру тому же .doc ,
D_T> и внутри много повторяющихся элементов. Зато что бы сделать экспорт какого — нить отчета
D_T>в rtf, много сил не надо, а попробуй сохрани в doc !

D_T>Вообще есть уже такой протокол -IIOP называется (CORBA), компактный до жути
D_T>и DCOM из той же оперы... вот только сложно очень с ними , брокеры нужны всякие,
D_T>а они не под все платформы есть. Ведь в чем прелесть XML — есть у тебя библиотека для него
D_T>- ок сфрмировал XML через объекты, нет — собрал из строчек. а когда разобрать надо , то даже без парсера,
D_T>если знаешь заранее структуру, данные можно вытащить. Переслал по http — вот тебе уже и SOAP


D_T>а если тормроза начинаются то это не XML виноват, скорее это ошибка проектирования.
D_T>для больших объемов(>1мб) XML мало подходит.

D_T>Ведь есть же DIME например, почему не писать данные туда ?

D_T>или сделать обмен через CORBA у нее самый маленький траффик.


Было несколько реализаций на CORBA — пришлось все переписывать именно в силу неэффективности использования канала


С Уважением Сергей Чикирев

Когда-то двое всем известных K&R придумали собственный язык и написали на нем, подумать только, ядро операционнй системы вместо ассемблера, что более чем в два раза увеличило ее объем, сначала все посмотрели на это с усмешкой ... ну а продолжение все знают

Здравствуйте, Sinclair, Вы писали:

S>А почему вы думаете, что запрос к MS SQL должен возвращать непременно тысячи строк? Каноническое клиент-серверное приложение никогда так не делает. Возвращается сравнительно небольшой набор данных, при которых накладные расходы при передаче по TDS могут быть сравнимы с потерями в XML. Зато последний имеет преимущество в том, что его можно напрямую скормить XSL-трансформатору для выкидывания в веб-страницу.
А если отчет надо замутить? Они ведь разные бывают, маленькие, БОЛЬШИЕ... Или это не относится к каноническому клиент-серверному приложению? =)

Здравствуйте, maksa, Вы писали:
M>А если отчет надо замутить? Они ведь разные бывают, маленькие, БОЛЬШИЕ... Или это не относится к каноническому клиент-серверному приложению? =)
Хм. А что такое большой отчет? Вот кому может понадобиться 100 страниц по 50 строк таблицы? Ты меня конечно, извини, но это бред. Если заказчик этого требует — значит он некомпетентен.
Подробнее:
Прочитать 500 строк табличных данных — выше человеческих сил. Как правило, подобные данные можно представить в каком-то агрегированном виде. И табличка будет не больше шахматной доски. Типа — по горизонтали кварталы, по вертикали подразделения. Все.
Проблема в том, что в такой табличке теряются важные подробности. За которыми и лезут в длинный отчет. Но эффективнее посмотреть "общим взглядом", а потом запросить уточненные данные по интересующему фрагменту. Которые тоже влезут в шахматную доску. Это называется OLAP, или средства поддержки принятия решений.
А 100 страниц, над которыми корпит бухгалтер — это, извините, прошлый век. Потому, что корпит он для проверки данных, которые теперь и так правильные.

Нда, работали мы как то с бинарными форматами
IMHO они АБСОЛЮТНО не применимы если формат пересылаемых часто меняется. Геморроя столько, что оказалось проще клиента (естественно это не обычный пользователь) заставить купить более мощную тачку и слать ему много данных (XML), но зато каждая следующая доработка обходилась ему на порядок дешевле (человеко/часы знаете ли )

subj относится и к XML тоже.
Есть вот например сайт http://webwarper.net/ww
и много подобного. Набираем любой урл и дальше лазим в вебе по бинарным данным. Трафик меньше в 3..10 раз. Так почему веб сервера досихпор гонят в сеть лажу в виде текстовых данных? Наверное чтобы провайдеры без хлеба не остались. Вышеуказанным товарисчам приходится шаманить, они закачивают запрошеные страницы к себе на сервак, перелопачивают их (ссылки подменяют на свои). И клиенту высылают уже в полноценном виде, т.е. запакованом через gzip. Неужели трудно всем вебсерверам высылать gzip чтоб шаманить не приходилось, в чем проблема? Если не все броузеры это поддерживают это их проблемы нефик прогресс тормозить, долго что-ли привинтить фичу.
И XML зачем нужен в текстовом виде, обясните кто-нибудь. Раз уж взялись за gzip пусть он будет стандартом сжатия текстовой лажи. Хотим подредактировать ручками XML'ный конфиг пожалуйста откроется програмка в которой в текстовом виде все будет (при сжатии распаковывает при сохранении сжимает). Пусть даже расширение останется XML. MSXML бы открывал такие файлы (предварительно распаковывая). А по сети уж мусор гонять это глупость. Как правильно сказал vladserge все начиналось с текстовых форматов но рано или поздно приходило к бинарному.
Парсится от этого они быстрее не будут, но хоть что-то.

ЗЫ. Куча полезной информации:
<VeryUsefulNumbers>
<VeryUsefulNumber>2</VeryUsefulNumber>
<VeryUsefulNumber>3</VeryUsefulNumber>
....
</VeryUsefulNumbers>
А может двухбуквенные названия тегов делать чтобы эффективность обмена данными повысить?

Здравствуйте, Lloyd, Вы писали:

L>Здравствуйте, Oxy, Вы писали:

Oxy>>А вместо того что бы разрабатывать бесплатные парсеры для XML слабо было разработать бессплатные же парсеры для ASN?

L>здесь

Ссылка битая. Перенесено на http://www.codeproject.com/csharp/Asn1Editor.asp

Здравствуйте, Silver_s, Вы писали:

S_>subj относится и к XML тоже.
S_>Есть вот например сайт http://webwarper.net/ww
S_>и много подобного. Набираем любой урл и дальше лазим в вебе по бинарным данным. Трафик меньше в 3..10 раз. Так почему веб сервера досихпор гонят в сеть лажу в виде текстовых данных? Наверное чтобы провайдеры без хлеба не остались. Вышеуказанным товарисчам приходится шаманить, они закачивают запрошеные страницы к себе на сервак, перелопачивают их (ссылки подменяют на свои). И клиенту высылают уже в полноценном виде, т.е. запакованом через gzip. Неужели трудно всем вебсерверам высылать gzip чтоб шаманить не приходилось, в чем проблема? Если не все броузеры это поддерживают это их проблемы нефик прогресс тормозить, долго что-ли привинтить фичу.
S_> И XML зачем нужен в текстовом виде, обясните кто-нибудь. Раз уж взялись за gzip пусть он будет стандартом сжатия текстовой лажи. Хотим подредактировать ручками XML'ный конфиг пожалуйста откроется програмка в которой в текстовом виде все будет (при сжатии распаковывает при сохранении сжимает). Пусть даже расширение останется XML. MSXML бы открывал такие файлы (предварительно распаковывая). А по сети уж мусор гонять это глупость. Как правильно сказал vladserge все начиналось с текстовых форматов но рано или поздно приходило к бинарному.
S_> Парсится от этого они быстрее не будут, но хоть что-то.

Ответ на твои вопросы почему очень простой: потому что для таких xml'ек и html'ек были бы нужны специальные редакторы,обычным текстовым тут уже не обойдешься( ты сам в принципе и ответил на вопрос почему). Так вот этот минус перевесил бы все плюсы которые ты перечислил.
По поводу "тормозить прогресс": собственно прогресс в области IT заключается в увелечении мощностей компьютеров, сетей и т.п. и, за счет этого, упрощения процесса разработки программ. Чем дальше, тем меньше кого-то волнует какие компы стоят у конечного пользователя или какой у него коннект к инету, главное это скорость разработки...

Здравствуйте, Nikto, Вы писали:

N>Здравствуйте, Silver_s, Вы писали:

S_>>subj относится и к XML тоже.
S_>>Есть вот например сайт http://webwarper.net/ww
S_>>и много подобного. Набираем любой урл и дальше лазим в вебе по бинарным данным. Трафик меньше в 3..10 раз. Так почему веб сервера досихпор гонят в сеть лажу в виде текстовых данных? Наверное чтобы провайдеры без хлеба не остались. Вышеуказанным товарисчам приходится шаманить, они закачивают запрошеные страницы к себе на сервак, перелопачивают их (ссылки подменяют на свои). И клиенту высылают уже в полноценном виде, т.е. запакованом через gzip. Неужели трудно всем вебсерверам высылать gzip чтоб шаманить не приходилось, в чем проблема? Если не все броузеры это поддерживают это их проблемы нефик прогресс тормозить, долго что-ли привинтить фичу.
S_>> И XML зачем нужен в текстовом виде, обясните кто-нибудь. Раз уж взялись за gzip пусть он будет стандартом сжатия текстовой лажи. Хотим подредактировать ручками XML'ный конфиг пожалуйста откроется програмка в которой в текстовом виде все будет (при сжатии распаковывает при сохранении сжимает). Пусть даже расширение останется XML. MSXML бы открывал такие файлы (предварительно распаковывая). А по сети уж мусор гонять это глупость. Как правильно сказал vladserge все начиналось с текстовых форматов но рано или поздно приходило к бинарному.
S_>> Парсится от этого они быстрее не будут, но хоть что-то.

N>Ответ на твои вопросы почему очень простой: потому что для таких xml'ек и html'ек были бы нужны специальные редакторы,обычным текстовым тут уже не обойдешься( ты сам в принципе и ответил на вопрос почему). Так вот этот минус перевесил бы все плюсы которые ты перечислил.
N>По поводу "тормозить прогресс": собственно прогресс в области IT заключается в увелечении мощностей компьютеров, сетей и т.п. и, за счет этого, упрощения процесса разработки программ. Чем дальше, тем меньше кого-то волнует какие компы стоят у конечного пользователя или какой у него коннект к инету, главное это скорость разработки...

В качестве справки:
Протокол HTTP допускает сжатие передоваемого контента, к примеру, gzip'ом. Насколько я понимаю, многие браузеры и веб-сервера эту фичу поддерживают. Так что речь о сжатии передаваемых данных, а не хранимых на сервере файликов.

Здравствуйте, Nikto, Вы писали:

N>Здравствуйте, Silver_s, Вы писали:

S_>>subj относится и к XML тоже.
S_>>Есть вот например сайт http://webwarper.net/ww
S_>>и много подобного. Набираем любой урл и дальше лазим в вебе по бинарным данным. Трафик меньше в 3..10 раз. Так почему веб сервера досихпор гонят в сеть лажу в виде текстовых данных? Наверное чтобы провайдеры без хлеба не остались. Вышеуказанным товарисчам приходится шаманить, они закачивают запрошеные страницы к себе на сервак, перелопачивают их (ссылки подменяют на свои). И клиенту высылают уже в полноценном виде, т.е. запакованом через gzip. Неужели трудно всем вебсерверам высылать gzip чтоб шаманить не приходилось, в чем проблема? Если не все броузеры это поддерживают это их проблемы нефик прогресс тормозить, долго что-ли привинтить фичу.
S_>> И XML зачем нужен в текстовом виде, обясните кто-нибудь. Раз уж взялись за gzip пусть он будет стандартом сжатия текстовой лажи. Хотим подредактировать ручками XML'ный конфиг пожалуйста откроется програмка в которой в текстовом виде все будет (при сжатии распаковывает при сохранении сжимает). Пусть даже расширение останется XML. MSXML бы открывал такие файлы (предварительно распаковывая). А по сети уж мусор гонять это глупость. Как правильно сказал vladserge все начиналось с текстовых форматов но рано или поздно приходило к бинарному.
S_>> Парсится от этого они быстрее не будут, но хоть что-то.

N>Ответ на твои вопросы почему очень простой: потому что для таких xml'ек и html'ек были бы нужны специальные редакторы,обычным текстовым тут уже не обойдешься( ты сам в принципе и ответил на вопрос почему). Так вот этот минус перевесил бы все плюсы которые ты перечислил.
N>По поводу "тормозить прогресс": собственно прогресс в области IT заключается в увелечении мощностей компьютеров, сетей и т.п. и,
.... ну как интересно, а !!!

N> за счет этого, упрощения процесса разработки программ.
..... без комментариев


N>Чем дальше, тем меньше кого-то волнует какие компы стоят у конечного пользователя или какой у него коннект к инету, главное это N>скорость разработки...

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



Сергей Чикирев

А можно узнать, какого рода программы Вы пишите и на какие рессурсы они ориентированны

Здравствуйте, mikkri, Вы писали:

M>Здравствуйте, Nikto, Вы писали:

N>>Здравствуйте, Silver_s, Вы писали:

N>>Ответ на твои вопросы почему очень простой: потому что для таких xml'ек и html'ек были бы нужны специальные редакторы,обычным текстовым тут уже не обойдешься( ты сам в принципе и ответил на вопрос почему). Так вот этот минус перевесил бы все плюсы которые ты перечислил.
N>>По поводу "тормозить прогресс": собственно прогресс в области IT заключается в увелечении мощностей компьютеров, сетей и т.п. и, за счет этого, упрощения процесса разработки программ. Чем дальше, тем меньше кого-то волнует какие компы стоят у конечного пользователя или какой у него коннект к инету, главное это скорость разработки...

M>В качестве справки:
M>Протокол HTTP допускает сжатие передоваемого контента, к примеру, gzip'ом. Насколько я понимаю, многие браузеры и веб-сервера эту фичу поддерживают. Так что речь о сжатии передаваемых данных, а не хранимых на сервере файликов.

С проксями это не работает, даже ч/з этот сайт... А с его точкой зрения по поводу XML ты тоже согласен?

Здравствуйте, Nikto, Вы писали:

<skipped>

N>С проксями это не работает, даже ч/з этот сайт... А с его точкой зрения по поводу XML ты тоже согласен?

Про сжатие HTTP понятно.

С тем, что сжимать XML полезно — я согласен...
Но здесь принципиальным становится "прозрачность" такого сжатия. Например, сжатие файла средствами NTFS никак не влияет на доступность данного файла для прикладных приложений. Если же XML сжимать явно (как class файлы сжимают в Java при помещении в jar), то существенно сузится удобство применения XML, так как далеко не все программные среды имеют встроенную поддержку сжатия и далеко не все редакторы умеют на лету расжимать и сжимать файлы.
Надеюсь, моя точка зрения понятна .

Здравствуйте, Nikto, Вы писали:

N>С проксями это не работает, даже ч/з этот сайт... А с его точкой зрения по поводу XML ты тоже согласен?

Странно что с проксями не работает. Может просто в IE не поставил галочку
-use HTTP 1.1
и
-use HTTP 1.1 through proxy connections.

Сжатие gzip'ом это еще не бинарный формат, это уловка не от хорошей жизни придуманая.
Да и gzip не максимальное сжатие обеспечивает.

А разработать универсальный двоичный формат можно было бы, да хотябы словарь тегов в XML сделать, а потом битиками их представлять. Это сразу бы как он полегчал. Массивы из сотни одинаковых тегов очень неэффективно в текстовом формате представлены.
А notepad'ом я никогда не пользовался. Чтоб редактировать ручками, хотябы подсветку непомешало бы иметь и автозакрытие тегов, а это уже специальный инструмент.

Здравствуйте, Silver_s, Вы писали:

S_>Здравствуйте, Nikto, Вы писали:

N>>С проксями это не работает, даже ч/з этот сайт... А с его точкой зрения по поводу XML ты тоже согласен?

S_>Странно что с проксями не работает. Может просто в IE не поставил галочку
S_>-use HTTP 1.1
S_>и
S_>-use HTTP 1.1 through proxy connections.

S_>Сжатие gzip'ом это еще не бинарный формат, это уловка не от хорошей жизни придуманая.
S_>Да и gzip не максимальное сжатие обеспечивает.

S_>А разработать универсальный двоичный формат можно было бы, да хотябы словарь тегов в XML сделать, а потом битиками их представлять. Это сразу бы как он полегчал. Массивы из сотни одинаковых тегов очень неэффективно в текстовом формате представлены.
В WAP'е помоему как раз так и делают, есть даже какойто стандарт и транслятор, те пишут wap сайт в XML а потом транслируют в бинарник.