С удивлением наблюдаю ажиотаж вокруг XML как "крутого" средства обмена данными. Мож я чего недопонимаю.... просветите.
Давным-давно появился на свет такой формат хранения данных .DBF и одним из его преимуществ было то, что смотреть, а иногда даже и править данные в нём можно было с помощью обыкновенного DOS редактора. Числа там, в частности, как и в XML, хранились в виде строки. Со временем стало очевидным сомнительность данного достоинства. И появились базы данных с нормальным, бинарным хранением информации. Например, Access. Конечно, просматривать, а уж тем более редактировать mdb – шник имеет смысл только с помощью специализированных библиотек DAO. Эту эволюцию я понимаю с информацией хранимой в бинарном виде, и работать проще и быстрее и хранить места меньше надо. А что с XML? Крайне не эффективный формат хранения, тем более передачи, информации! 60%(!) процентов мусора. Если, к примеру, сделать некоторую выборку из базы данных и сохранить её в бинарном формате то, та же информация, сохраненная в формате XML, будет занимать минимум в два раза больше места в среднем в 3.5 раза больше. Значит на её передачу уйдет больше времени. Да, перед передачей XML можно сжать, он очень хорошо сжимается (слишком много в нем ненужного). Но это означает что после передачи перед процессом парсирования, он должен быть разжат в памяти клиента (отожрать ресурс) в том объеме, в котором он был до сжатия. Я столкнулся с этой проблемой, когда занялся написанием клиент-серверного комплекса. Проблема в частности в том, что клиентская JAVA-программа должна быть в высшей степени жизнеспособной при минимально доступных ресурсах у пользователей. Пришлось разработать свой протокол обмена и хранения информации, что оказалось совсем не сложным делом. Бинарное представление + сжатие перед передачей и Всё просто летает! Так вот, если единственным плюсом XML осталась универсальность, унифицированность и межплатформенность так неужели нельзя было договориться о некотором бинарном формате обмена? Кто нибудь использует XML формат ответов в MS SQL? Вам это не очевидно?
Serge
14.07.03 21:06: Перенесено модератором из 'Базы данных' — M
Здравствуйте, vladserge, Вы писали:
V>Привет всем!
V>XML как "крутого" средства обмена данными. V>хранения данных .DBF
XML удобен когда у тебя существует один клиент и несколько источников(зачастую разработынных третьеми производителями), поставляющие данные в различных форматах...
Здравствуйте, vladserge, Вы писали:
V>Привет всем!
V>сжатие перед передачей и Всё просто летает! Так вот, если единственным плюсом XML осталась универсальность, унифицированность и межплатформенность так неужели нельзя было договориться о некотором бинарном формате обмена? Кто нибудь использует XML формат ответов в MS SQL? Вам это не очевидно?
Пользуем XML для передачи данных между платформами Win — Linux, по протоколу HTTP, в следствии чего поиспользовать бинарный формат не получается, но сжатие все равно используем, только немного для другого... gzip. Исходники есть и под Win и под Linux и в Mac — gzip — GNU Project.
А по поводу официального формата сжатия для XML.. года три назад, на конференции Microsoft, как раз посвященной XML, задавали этот вопрос представителям, но они только пожали плечами... мол дело хорошее но у них в планах этого нет.
Здравствуйте, Alexey Shirshov, Вы писали:
AS>Здравствуйте, vladserge, Вы писали:
V>>Привет всем!
V>>Бинарное представление + сжатие перед передачей и Всё просто летает!
AS>ну есть DIME.
Direct Internet Message Encapsulation (DIME)
нет это не то, под бинарным форматом я имел ввиду byte=1 byte, short=2 byte, int=4 byte, long=8 byte ......
V>>Так вот, если единственным плюсом XML осталась универсальность, унифицированность и межплатформенность ...
AS>не так уж и мало.
V>>...так неужели нельзя было договориться о некотором бинарном формате обмена?
AS>Попробуй, договорись.
V>>Кто нибудь использует XML формат ответов в MS SQL?
AS>Я.
локальная сеть? я знаю один проект который в реале по интернету использовал web service, SOAP это оффлайновый клиент чтения RSDN форумов.Народ задавался вопросом отчего такой гигантский трафик ..... а вот, технология такая
V>>XML как "крутого" средства обмена данными. V>>хранения данных .DBF
СС>XML удобен когда у тебя существует один клиент и несколько источников(зачастую разработынных третьеми производителями), поставляющие данные в различных форматах...
XML — на безптичьи ж.. соловей. Вот и не поняно почему нельзя было сделать и предложить нечто более продуманое.
Почему цифры нельзя было представлять в бинарном виде? Почему?
Ведь строковое 2 147 483 647 можно передать с помощью 4 byte вместо 10.
С уважением Сергей Чикирев
А про повторяющиеся по всему файлу теги( порой совершенно кигантской длинны) ....... молчу.
Здравствуйте, kly, Вы писали:
kly>Здравствуйте, vladserge, Вы писали:
V>>Привет всем!
kly>А теперь представь, что некто должен написать приладу к твоей клиент-серверной системе! Он начинает читать написанную тобой доку, смотреть примеры исходного кода, а тут еще оказалось, что твой комплекс работает в LittleEndian, а прилада — BigEndian. Он начинает вертеть у себя инты и т.д. Но все это естественно, мелочи, все обходится и прилада, таки начинает работать. Опять велосипеды, вникать в что-то чужое и т.д. Стандартным пользоваться удобнее! Парсеры, написаны, отлажены и т.д. А излишний объем — плата за унифицированность! Кроме того, XML — верхушка айзберга, над ним лежат такие чудные вещи, как xpath, xquery, xslt ! А схемы xml, для selfmade-протокола — selfmade validator, надоело. Беда в том, что многие люди начинают относиться к xml, как к панацее, а это в корне неверно, всякая технология имеет свои границы применимости. kly>Интерестно, а когда появился SQL, такие вопросы в конфах тоже плавали? И вообще этот вопрос — скорее в категорию "Общие вопросы >> О жизни "
Вот я и говорю порпробовав XML плюнул и начал изобретать велосипед, перед этим внимательно изучив чужие.
Заметил что многие системы эволюционируют так же как и наша. Сначала сделали на XML (потому что повелись на рекламу) и все было хорошо пока инф.система раскачивалась и наполнялась. Сотня записей на запрос загружалась быстро. В системе начала прибывать информация и тот самый запрос на который раньше возвращалось 100 записей стало загружаться 500 записей, 1000. И вот тут начались кранты ... Сжатие потока решило проблему передачи но проблему хилых клиентов с малой памятью не решило... ВСЁ пришлось переделать. Просто хочу предостеречь от своих ошибок. Вся проблемма оказалась в протоколе. Жаль что нет общепринятого бинарного формата обмена.
Тут народ уже привел несколько доводов в защиту XML.
Вот еще довод, когда XML нужен. Очень удобно XML-данные преобразовывать в разные форматы с помощью XSLT.
Была такая контора ВТрэйд, у них например, пользовательский интерфейс лежал в XML, а его представление для различных устройствах с разными форматами (телефоны разных типов, мобильные ПК, записные книжки, да и просто разные браузеры) генерилось с помощью специфичных для этих устройств XSLT-преобразований. Круто и таких примеров использования можно привести много.
Но я согласен, некоторые товарищи слишком уж зацикливаются на XML, типа модно и все тут, делаем все на XML.
XML-следует использовать тогда, когда это действительно нужно.
Здравствуйте, Vitaton, Вы писали:
V>Здравствуйте, vladserge, Вы писали:
V>Тут народ уже привел несколько доводов в защиту XML. V>Вот еще довод, когда XML нужен. Очень удобно XML-данные преобразовывать в разные форматы с помощью XSLT.
V>Была такая контора ВТрэйд, у них например, пользовательский интерфейс лежал в XML, а его представление для различных устройствах с разными форматами (телефоны разных типов, мобильные ПК, записные книжки, да и просто разные браузеры) генерилось с помощью специфичных для этих устройств XSLT-преобразований. Круто и таких примеров использования можно привести много.
не, хотя я больше акцентировал внимание на передачу данных даже для хранения и обработки XML НЕ ЭФФЕКТИВЕН
ну зачем ? для чего ? теги именно такие типа <tr /tr> <td /td> хотя можно было условится заменить их неким байт кодом иного обяснения кроме как возможность править HTML с помощью текстового редактора не вижу.
на заре HTML это было логично, но сейчас когда "космические корабли которые бороздили космическое пространство ... давно сданы в утиль" а практически 99.9999% информации в HTML формате либо генерится в автомате либо созданно человеком в специализированных редакторах. HTML — атавизм а XML — назад в будущее
V>Но я согласен, некоторые товарищи слишком уж зацикливаются на XML, типа модно и все тут, делаем все на XML. V>XML-следует использовать тогда, когда это действительно нужно.
Согласен много полезного уже сделано на основе XML но если бы этот формат был бы ещё и бинарным то ценность его возросла значительно
Здравствуйте, vladserge, Вы писали:
V>Здравствуйте, Сан Саныч, Вы писали:
V>>>XML как "крутого" средства обмена данными. V>>>хранения данных .DBF
СС>>XML удобен когда у тебя существует один клиент и несколько источников(зачастую разработынных третьеми производителями), поставляющие данные в различных форматах...
V>XML — на безптичьи ж.. соловей. Вот и не поняно почему нельзя было сделать и предложить нечто более продуманое. V>Почему цифры нельзя было представлять в бинарном виде? Почему?
V>Ведь строковое 2 147 483 647 можно передать с помощью 4 byte вместо 10.
V>С уважением Сергей Чикирев
V>А про повторяющиеся по всему файлу теги( порой совершенно кигантской длинны) ....... молчу.
Ты прав... но единого стандарта передачи бинарной информации нет и в ближайшие годы непредвидится...... писать для каждого нового источника данных провыйдер позволяющий преобразовать информации к понимаемой твоим клиентом форме?
И потом зачем обязательно гонять по сети XML... получай бинарную информацию и преобразуй ей в XML уже на стороне клиента...
Здравствуйте, vladserge, Вы писали:
V>Здравствуйте, Vitaton, Вы писали:
V>>Здравствуйте, vladserge, Вы писали:
V>>Тут народ уже привел несколько доводов в защиту XML. V>>Вот еще довод, когда XML нужен. Очень удобно XML-данные преобразовывать в разные форматы с помощью XSLT.
V>>Была такая контора ВТрэйд, у них например, пользовательский интерфейс лежал в XML, а его представление для различных устройствах с разными форматами (телефоны разных типов, мобильные ПК, записные книжки, да и просто разные браузеры) генерилось с помощью специфичных для этих устройств XSLT-преобразований. Круто и таких примеров использования можно привести много.
V>не, хотя я больше акцентировал внимание на передачу данных даже для хранения и обработки XML НЕ ЭФФЕКТИВЕН V>ну зачем ? для чего ? теги именно такие типа <tr /tr> <td /td> хотя можно было условится заменить их неким байт кодом иного обяснения кроме как возможность править HTML с помощью текстового редактора не вижу. V>на заре HTML это было логично, но сейчас когда "космические корабли которые бороздили космическое пространство ... давно сданы в утиль" а практически 99.9999% информации в HTML формате либо генерится в автомате либо созданно человеком в специализированных редакторах. HTML — атавизм а XML — назад в будущее
Понятие эффективности — очень расплвчатое, эффективность можно оценивать по разным критериям.
Вот еще пример. У Вас есть два бинарных файла с данными с разными спецификациями, и Вам нужно один преобразовать в другой программно. Или есть два XML файла с данными (с разными XML-схемами) с той же задачей преобразовать один в другой. Так вот во втором случае Вы спарвитесь с задачей преобразования файла из одного в другой в несколько раз быстрее просто набросав XSLT-преобразование.Т.е. конверторы разрабюатываюся значительно быстрее и проще и с меньшим количеством ошибок.
В Вашем случае, я конечно не знаю деталей, но я не уверен следовало ли вообще использовать XML, может было проще и быстрее ,skj разработаnь свой формат передачи данных, если не требовалось решать тех задач, которые позволяет решать XML.
V>>Но я согласен, некоторые товарищи слишком уж зацикливаются на XML, типа модно и все тут, делаем все на XML. V>>XML-следует использовать тогда, когда это действительно нужно.
V>Согласен много полезного уже сделано на основе XML но если бы этот формат был бы ещё и бинарным то ценность его возросла значительно
Так сложно договориться насчет бинарного стандарта и пока как-то не получается. А насчет XML уже кое-какие шига вперед сделаны.
Полностю согласен со всеми аргументами vladserge. Это совсем ненужный формат. Вернее унификация, которую он предлагает нужна, но решение этой задачи совсем кривое. Текст занимает огромные объемы и скорость его обработки крайне мала.
V>Так сложно договориться насчет бинарного стандарта и пока как-то не получается. А насчет XML уже кое-какие шига вперед сделаны.
Ну вот не понимаю иногда этих разработчиков. Разработать текстовой формат и договориться они кое как сумели, а потратить это время на разработку универсального бинарного формата и договориться о его использовании не смогли...
Но, возможно, здесь есть скрытые подводные камни. Если разрабатывать бинарный формат, то дело в конце концов наткнулось бы на чьи то интересы. Ведь уже много лет различные производители выдумывают свои форматы храниеия данных (Oracle, MS и др.) Они разработали эффективные бинарные структуры хранения данных и новый универсальный формат неизбежно в какой то мере должен был бы использовать часть этих идей. И кому то это бы не понравилось. Начались бы всякие судебные тяжбы и все такое...
Здравствуйте, vladserge, Вы писали:
V>Жаль что нет общепринятого бинарного формата обмена.
Почему же? Есть, например, ASN.1. Детально описывает структуру бинарных данных. Только вот парсеры для него все платные.
Здравствуйте, heathcliff, Вы писали:
H>Здравствуйте, vladserge, Вы писали:
V>>Жаль что нет общепринятого бинарного формата обмена. H>Почему же? Есть, например, ASN.1. Детально описывает структуру бинарных данных. Только вот парсеры для него все платные.
Дык я же не собираюсь их руками править. Для этого создаются спец. механизмы. Ты где то видел что бы в серьезных продуктах пользователь руками правил данные?
Здравствуйте, heathcliff, Вы писали:
H>Здравствуйте, Сан Саныч, Вы писали:
СС>>ASN.1 принципиально ничем не отличается от XML H>Хм... Что тогда принципиально отличается от XML?
V>>Жаль что нет общепринятого бинарного формата обмена. H>Почему же? Есть, например, ASN.1. Детально описывает структуру бинарных данных. Только вот парсеры для него все платные.
А вместо того что бы разрабатывать бесплатные парсеры для XML слабо было разработать бессплатные же парсеры для ASN?
Здравствуйте, Сан Саныч, Вы писали:
СС>Здравствуйте, vladserge, Вы писали:
V>>Здравствуйте, Сан Саныч, Вы писали:
V>>>>XML как "крутого" средства обмена данными. V>>>>хранения данных .DBF
СС>>>XML удобен когда у тебя существует один клиент и несколько источников(зачастую разработынных третьеми производителями), поставляющие данные в различных форматах...
V>>XML — на безптичьи ж.. соловей. Вот и не поняно почему нельзя было сделать и предложить нечто более продуманое. V>>Почему цифры нельзя было представлять в бинарном виде? Почему?
V>>Ведь строковое 2 147 483 647 можно передать с помощью 4 byte вместо 10.
V>>С уважением Сергей Чикирев
V>>А про повторяющиеся по всему файлу теги( порой совершенно кигантской длинны) ....... молчу.
СС>Ты прав... но единого стандарта передачи бинарной информации нет и в ближайшие годы непредвидится...... писать для каждого нового источника данных провыйдер позволяющий преобразовать информации к понимаемой твоим клиентом форме?
СС>И потом зачем обязательно гонять по сети XML... получай бинарную информацию и преобразуй ей в XML уже на стороне клиента...
.....а я про Ерёму. Ведь откуда взялась эта тема XML парсеров, их быстродействия именно из-за сложности разобрать XML данные быстро и сделать это эффективно ( в контексте затраченных рессурсов). А если проследить куда потом эти данные ложаться то чаще всего они преобразуются в бинарный вид и в этом виде хранятся в виде полей классов и значений в массиве. В БИНАРНОМ ВИДЕ ЗАМЕТЬТЕ
прикольная была бы програмуля у которой у классов все поля текстовые даже salary и age
[]
Oxy>Дык я же не собираюсь их руками править. Для этого создаются спец. механизмы. Ты где то видел что бы в серьезных продуктах пользователь руками правил данные?
При чем здесь руки?
Я тебе сказал о концепциях, которые заложены в XML. А в твою концепцию бинарного формата заложена лишь собственная неопытность и недальновидность.
XML — логическое развитие SQML, которому лет 15 минимум. Неужели ты думаешь, что за это время люди не могли придти к верному решению?
Если тебе нужна производительность — используй SOAP/DIME или Remoting с binary форматером.
V>.....а я про Ерёму. Ведь откуда взялась эта тема XML парсеров, их быстродействия именно из-за сложности разобрать XML данные быстро и сделать это эффективно ( в контексте затраченных рессурсов). А если проследить куда потом эти данные ложаться то чаще всего они преобразуются в бинарный вид и в этом виде хранятся в виде полей классов и значений в массиве. В БИНАРНОМ ВИДЕ ЗАМЕТЬТЕ
V>прикольная была бы програмуля у которой у классов все поля текстовые даже salary и age
Действительно прикольная программа получится... но тут мне видится проблема не в XML а в кривых руках рахработчиков.
Здравствуйте, Сан Саныч, Вы писали:
H>>Хм... Что тогда принципиально отличается от XML? СС>то что не является расширяемым языком разметки.
Как тогда договариваемся о формате бинарных данных?
Здравствуйте, Alexey Shirshov, Вы писали:
AS>Здравствуйте, Oxy, Вы писали:
AS>[]
Oxy>>Дык я же не собираюсь их руками править. Для этого создаются спец. механизмы. Ты где то видел что бы в серьезных продуктах пользователь руками правил данные?
AS>При чем здесь руки? AS>Я тебе сказал о концепциях, которые заложены в XML. А в твою концепцию бинарного формата заложена лишь собственная неопытность и недальновидность. AS>XML — логическое развитие SQML, которому лет 15 минимум. Неужели ты думаешь, что за это время люди не могли придти к верному решению?
AS>Если тебе нужна производительность — используй SOAP/DIME или Remoting с binary форматером.
....не понял простити в чём расширяемость? Если посмотрим на реляционные (и не только) базы данных то обнаружим в среднем десяток наиболее употребимых типов данных которые разве отличаются только названиями.
А ВОТ ВСЕ ПРИЛОЖЕНИЯ которые написаны с использованием этих базовых типов и есть расширения под конкретные цели. Что нетак ?
Здравствуйте, heathcliff, Вы писали:
H>Здравствуйте, vladserge, Вы писали:
V>>Жаль что нет общепринятого бинарного формата обмена. H>Почему же? Есть, например, ASN.1. Детально описывает структуру бинарных данных. Только вот парсеры для него все платные.
Оказывается это целая война миров !!!!
Очень рекомендую прочитать всем !!!!
Здравствуйте, vladserge, Вы писали:
V>А ВОТ ВСЕ ПРИЛОЖЕНИЯ которые написаны с использованием этих базовых типов и есть расширения под конкретные цели. Что нетак ?
Почему же тогда для обозначения полей в таблицах и самих таблиц используются названия, а не бинарные коды? Почему не сохранил своих позиций формат EDI?
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, vladserge, Вы писали:
V>>А ВОТ ВСЕ ПРИЛОЖЕНИЯ которые написаны с использованием этих базовых типов и есть расширения под конкретные цели. Что нетак ?
А>Почему же тогда для обозначения полей в таблицах и самих таблиц используются названия, а не бинарные коды? Почему не сохранил своих позиций формат EDI?
Всё большое спасибо ВСЕМ кто поучавствовал. Меня натыкали в стандарт ASN1
The military makes extensive use of binary formatted messages for efficient wireless communications and processing
by automated systems. These message standards are typically crafted to express field content and structure using
the fewest bits possible. Design approaches vary but normally the binary physical encoding of the structure and
fields are captured by rules unique to each specification.
........
Use of wireless XML poses problems due to the explosion in the number of
bytes required to represent the same data and the limits of radio spectrum availability. Additionally, processing of
XML is relatively more expensive in terms of CPU and memory which may be a limiting factor for embedded
processors.
The XML community generally regards loss of format efficiency as necessary to achieve the benefits they espouse.
List discussions on the topic divide into two camps, the XML purists who wish to defend attacks on the technology
and outsiders who are grappling with the disruptions that this technology engenders. Purist argue that XML can
be compressed if space/bandwidth is an issue while outsiders argue that alternate encodings are needed to provide
efficient data exchange and consumption by applications which are concerned only with the data content, not the
presentation.
This study investigates the costs of converting one binary message format into XML and the application of
several XML compression and encoding methods to reduce the resulting XML message sizes. Our goal is to run
concrete tests in order to produce comparative metrics for analysis and draw conclusions as warranted.
С Уважением Сергей Чикирев
PS Задумайтесь сегодня не то Ваше XML based application заставит вас задуматься завтра .... как раз в тот момент когда Вы к этому не расположены
Никакой разницы. Какая разница, если всё равно используется интерфейс для доступа к данным?
AS>Вся идея заключается в наглядности, самодокументируемости и расширяемости.
"Самодокументируемость" — очень вредное слово. Не бывает таковой, в принципе.
AS>Как ты себе представляешь бинарный расширяемый формат?
Точно так же, как текстовый расширяемый. Абсолютно.
----------
Если говорить вообще, то в IT любой текст — маздай кроме специальных тексто-ориентированных приложений.
Не удивляет же, что GetLastError() отдаёт число, и уже потом по нему можно получить локализованное описание ошибки?
Кстати.. Вот и <name>Alexey Shirshov</name> совсем не то же, что <имя>Alexey Shirshov</имя>, верно? Если уж говорим про "самодокументируемость"???
Здравствуйте, vladserge, Вы писали:
V>С удивлением наблюдаю ажиотаж вокруг XML как "крутого" средства обмена данными. Мож я чего недопонимаю.... просветите.
[skip]
Здравствуйте, vladserge, Вы писали:
V>Привет всем!
V>С удивлением наблюдаю ажиотаж вокруг XML как "крутого" средства обмена данными. Мож я чего недопонимаю.... просветите.
Что-то я не понял, что за проблемы у тебя? Мне вот, например, для решения моих задач совсем не подходит ассемблер — это ведь не значит что я должен на всех углах кричать, что ассемблер это хрень не нужная и не оптимальная ?
Если кто-то использует XML, значит XML подходит для решения его задач...
Конкретно к твоей проблеме на сколько я понимаю ты не был знаком с предметной областью( или вернее сказать с задачами такого рода), поэтому не знал что тебе использовать хорошо, а что плохо, поэтому не правильно выбрал вначале XML. Вот и все дела. Глупо из-за одного "прокола" отказываться от XML ообще...
Всякое оружие хорошо для своих целей. Почему-то в армии до сих пор выдают штык-ножи, несмотря на танковые клинья и тактическое ядерное оружие. Обвинять XML в том, что он плохо подходит для передачи больших объемов реляционных данных — глупо. Он просто не для этого разработан. Я лично считаю, что по сравнению с .ini конфигами XML конфиги рулят однозначно. А бинарные форматы фиксированной структуры плохи для сериализации сильно разветвленных древовидных данных. В общем, по задаче и инструмент.
... << RSDN@Home 1.1 alpha 1 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, vladserge, Вы писали:
V>PS Задумайтесь сегодня не то Ваше XML based application заставит вас задуматься завтра .... как раз в тот момент когда Вы к этому не расположены
Ты слышал про такую вещь как Web Services? Эту технологию развивают очень серьезные компании и только из-за
нее XML не умрет (как и Floppy 10 лет душат), а ведь это всего 1 пример
К тому же пропускные способности каналов постоянно растут, да, ты же не играешь в UGH! когда у тебя Р4 только
из-за того что он бегает быстрее чем Doom3
Здравствуйте, Dmitry123, Вы писали:
D>Здравствуйте, vladserge, Вы писали:
V>>PS Задумайтесь сегодня не то Ваше XML based application заставит вас задуматься завтра .... как раз в тот момент когда Вы к этому не расположены
D>Ты слышал про такую вещь как Web Services? Эту технологию развивают очень серьезные компании и только из-за D>нее XML не умрет (как и Floppy 10 лет душат), а ведь это всего 1 пример
Логика, СУПЕР !!! А ещё, в догонку, мильён мух не могут ошибаться .....
D>К тому же пропускные способности каналов постоянно растут, да, ты же не играешь в UGH! когда у тебя Р4 только D>из-за того что он бегает быстрее чем Doom3 ;
Всё правильно, просто мне показалось что здесь достаточно много людей которые стремятся выпускать конкурентноспособные продукты.
А рессурсы, ЛЮБЫЕ (!!!!) как и денеги НИГОГДА не бывают лишними.
Здравствуйте, vladserge, Вы писали:
V>Логика, СУПЕР !!! А ещё, в догонку, мильён мух не могут ошибаться .....
Ну это ты все-таки зря
Решил MS продвигать .NET и никуда он не денется, многие кричат что он плохой,
но если понадобится то будут учить, ничего не поделаешь.
Это я к тому, что не важно сколько корпораций стоит за XML, важно какие,
и им невыгодно его пока менять
V>Всё правильно, просто мне показалось что здесь достаточно много людей которые стремятся выпускать конкурентноспособные продукты. V>А рессурсы, ЛЮБЫЕ (!!!!) как и денеги НИГОГДА не бывают лишними.
Здравствуйте, vladserge, Вы писали: V>Читайте subj месье.
А почему вы думаете, что запрос к MS SQL должен возвращать непременно тысячи строк? Каноническое клиент-серверное приложение никогда так не делает. Возвращается сравнительно небольшой набор данных, при которых накладные расходы при передаче по TDS могут быть сравнимы с потерями в XML. Зато последний имеет преимущество в том, что его можно напрямую скормить XSL-трансформатору для выкидывания в веб-страницу.
Естественно, попытки использовать его для select * from EarthPopulation неразумны.
... << RSDN@Home 1.1 alpha 1 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, vladserge, Вы писали:
V>Здравствуйте, Аноним, Вы писали:
А>>Здравствуйте, vladserge, Вы писали:
V>>>А ВОТ ВСЕ ПРИЛОЖЕНИЯ которые написаны с использованием этих базовых типов и есть расширения под конкретные цели. Что нетак ?
А>>Почему же тогда для обозначения полей в таблицах и самих таблиц используются названия, а не бинарные коды? Почему не сохранил своих позиций формат EDI?
V>Всё большое спасибо ВСЕМ кто поучавствовал. Меня натыкали в стандарт ASN1
V>Настоятельно рекомендую прочитать http://asn1.elibel.tm.fr/en/biblio/cokus-xml-sizing.pdf
Этому стандарту очень много лет, гораздо меньше чем XML. Не настораживает почему он распрастранился гораздо меньше?
Если смотреть реально, то такие вещи как "читабельность" и "простота" играют важную роль.
Агрумент: есть специализтрованные средства — срабатывает далеко не всегда (хотя и часто ).
В свое время я расматривал возможность сделать собственный парсер для ASN.1 (как часть дипломной работы ).
После небольших размышлений, пришел к выводу: если начну его делать — не видать мне диплома. (все делалось по-русски: на грани deadline)
Хотел бы еще добавить, что насколько я помню, ASN.1 обязательно требует описание данных, иначе парсеры не смогут его обработать.
XML здесь более гибок. Нужна схема — делай, не нужна — не делай.
Второй момент — расширяемость. Создается очущение, что каждый понимает этот термин по своему, может это и правильно.
А понимаю его так: я могу добавить в XML файл нужный мне атрибут или элемент (в любое место), а старые программы попрежнему будут с ним работать без проблем.
В случае бинарных форматов пришлось бы обновлять схему данных и вероятность, что старые программы попрежнему будут работать на этих данных посему уменьшается.
Subj.
D>>Если говорить вообще, то в IT любой текст — маздай кроме специальных тексто-ориентированных приложений.
MAG>Вот так и появляются всякие винды глючные...
А то какие-то эмоции получаются галимые. Похоже на банальную глупость.
p.s. Кстати в "виндах глючных" как раз в этом отношении всё правильно. В отличие от...
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, vladserge, Вы писали: V>>Читайте subj месье. S>А почему вы думаете, что запрос к MS SQL должен возвращать непременно тысячи строк? Каноническое клиент-серверное приложение никогда так не делает. Возвращается сравнительно небольшой набор данных, при которых накладные расходы при передаче по TDS могут быть сравнимы с потерями в XML. Зато последний имеет преимущество в том, что его можно напрямую скормить XSL-трансформатору для выкидывания в веб-страницу. S>Естественно, попытки использовать его для select * from EarthPopulation неразумны.
Читаете ли вы посты по теме, (и не только свои), так как я это делаю ......
Убедительно (на сколько это возможно) рекомендую прочитать
что это означает? а то что 674,062 байт в ответ ещё можно ждать,
а вот 11,421,822 байт никто ждать не будет. Почувствуйте разницу ....
И даже(!) если применить сжатие перед пердачей с сервера на клиент после передачи клиенту нужно будет найти (отожрать) в памяти 11 мегов в полный рост. Потом парсировать (откусить от CPU)
и это(!) чаще всего для того чтобы сохранить локально в бинарном виде
V>локальная сеть? я знаю один проект который в реале по интернету использовал web service, SOAP это оффлайновый клиент чтения RSDN форумов.Народ задавался вопросом отчего такой гигантский трафик ..... а вот, технология такая
Слышал звон, не знаю где он. Гигантский это сколько? А еще я наглядно доказал что оказывается для янусовской БД формат хранения XML эффективнее чем бинарный в упомянутом Джете. Особенно после сжатия.
Здравствуйте, Dimentiy, Вы писали:
MAG>>Вот так и появляются всякие винды глючные...
D>А то какие-то эмоции получаются галимые. Похоже на банальную глупость.
Хм... Тогда вопрос: какой формат легче восстанавливать при сбое: виндовый реестр или юниксовую диру /etc?
Здравствуйте, vladserge, Вы писали:
V>И даже(!) если применить сжатие перед пердачей с сервера на клиент после передачи клиенту нужно будет найти (отожрать) в памяти 11 мегов в полный рост. Потом парсировать (откусить от CPU) V> и это(!) чаще всего для того чтобы сохранить локально в бинарном виде
V>Логика где?
Передавать 7 мегабайт данных из SQL-сервера на клиента — логика где?
AVK> А еще я наглядно доказал что оказывается для янусовской БД формат хранения XML эффективнее чем бинарный в упомянутом Джете. Особенно после сжатия.
Здравствуйте, <Аноним>, Вы писали:
AVK>> А еще я наглядно доказал что оказывается для янусовской БД формат хранения XML эффективнее чем бинарный в упомянутом Джете. Особенно после сжатия.
А>Где доказал?
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, vladserge, Вы писали:
V>>И даже(!) если применить сжатие перед пердачей с сервера на клиент после передачи клиенту нужно будет найти (отожрать) в памяти 11 мегов в полный рост. Потом парсировать (откусить от CPU) V>> и это(!) чаще всего для того чтобы сохранить локально в бинарном виде
V>>Логика где?
AVK>Передавать 7 мегабайт данных из SQL-сервера на клиента — логика где?
Здравствуйте, Алексей Владимирович Миронов, Вы писали:
MAG>>Хм... Тогда вопрос: какой формат легче восстанавливать при сбое: виндовый реестр или юниксовую диру /etc? АВМ>Тот, для которого есть backup.
+1
Я однажды уронил XP кривыми дровами дык после второй перезагрузки он продолжел работать как ни вчем не бывало. Я даже представить боюсь что надо будет сделать со следующими виндами чтобы они упали и не смоги встать...
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, WolfHound,
S>Warning: CPU not found. Please insert CPU and press Enter to continue. Press F8 for advanced emulation options
Не, не так, а во как: CPU not found. Press any key to software emulation.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Использовать XML для передачи данных в клиент/серверных приложениях нужно очень осторожно: нужно учитывать и возможный объем передаваемых данных и нагрузку на клиента для парсинга XML.
Если есть уверенность, что данных не разрастутся до неприлично больших размеров и клиенты довольно мощные и на хорошем канале, то можно спокойно рассматривать XML как вариант передачи данных (архивирование/не архивирование — это детали, по большому счету не оказывают существенного влияние на выбор: XML или нет). Опять же как вариант... Если нет никаких предпосылок использовать XML в настоящем и будущем, то гнаться за ним ради названия тоже не стоит.
Однако, например, если с выбором XML упрощается/ускоряется/"умощнается"/удешевляется разбаротка клиента — XML ваш выбор. И т.д.
Вариант многоуровневой архитектуры: здесь можно довольно точко сказать какая нагрузка ляжет на сервер приложений и сервер баз данных при переходе на XML и такие параметры траффик и затраты на парсинг стоят не так остро. Появляется большая гибкость в выборе. Опять же, только если от XML есть какая-нибудь выгода кроме названия. Например, зачастую, представление объектов в XML виде значительно облегчает хранение этих объектов в БД. Если вам это подходит — выбирайте XML.
Кроме того, использовать XML можно и для вспомогательных целей. Например для получения схемы данных в определенном формате, чтобы потом использовать эти данные, скажем, для построения классов объектов (например при помощи XSLT преобразования). При таком подходе, ни траффик, ни нагрузка на машину не играют никакой роли (это довольно редкая операция и производится, как правило, в течение цикла разработки программы)
Так что MSSQL+XML — это очень сильных ход. Но только там где он нужен и нигде более . Как на танке — на асфальте прокатишься, асфальт поломаешь; через болото поедишь, сам застрянешь....
D>Так что MSSQL+XML — это очень сильных ход. Но только там где он нужен и нигде более . Как на танке — на асфальте прокатишься, асфальт поломаешь; через болото поедишь, сам застрянешь....
Здравствуйте, Алексей Владимирович Миронов, Вы писали:
АВМ>Здравствуйте, m.a.g., Вы писали:
MAG>>Хм... Тогда вопрос: какой формат легче восстанавливать при сбое: виндовый реестр или юниксовую диру /etc?
АВМ>Тот, для которого есть backup.
В целом согласен. Меня это тоже немножко удивляет.
Есть небольшие потуги вроде XDR и ASN.1
Думаю все таки в будущем мы увидим стандарт на бинарное представление согласно схеме.
Если это будет так интересно кто победит в выборе представления бинарных данных, схема младший байт первым (MS, Linux) или старший первым (IBM/Aix, Sun/Solaris, MacOS)
Например в формате XDR который используется для межсетевого взаимодействия (RPC) победили последние. Но это потому что XDR начал свою историю в Sun.
Здравствуйте, maq, Вы писали:
maq>Если это будет так интересно кто победит в выборе представления бинарных данных, схема младший байт первым (MS, Linux) или старший первым (IBM/Aix, Sun/Solaris, MacOS)
При чем тут операционные системы? Порядок следования байт в слове определяется процессором.
Здравствуйте, maq, Вы писали:
maq>Если это будет так интересно кто победит в выборе представления бинарных данных, схема младший байт первым (MS, Linux) или старший первым (IBM/Aix, Sun/Solaris, MacOS)
При чем тут операционные системы? Порядок следования байт в слове определяется процессором.
Здравствуйте, 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 страниц, над которыми корпит бухгалтер — это, извините, прошлый век. Потому, что корпит он для проверки данных, которые теперь и так правильные.
... << RSDN@Home 1.1 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Нда, работали мы как то с бинарными форматами
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>здесь
Здравствуйте, 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 заключается в увелечении мощностей компьютеров, сетей и т.п. и, за счет этого, упрощения процесса разработки программ. Чем дальше, тем меньше кого-то волнует какие компы стоят у конечного пользователя или какой у него коннект к инету, главное это скорость разработки...
Re[3]: А какого хрена идиоты гоняют HTML по сетям?
Здравствуйте, 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'ом. Насколько я понимаю, многие браузеры и веб-сервера эту фичу поддерживают. Так что речь о сжатии передаваемых данных, а не хранимых на сервере файликов.
... << RSDN@Home 1.1 beta 1 >>
Re[3]: А какого хрена идиоты гоняют HTML по сетям?
Здравствуйте, 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>скорость разработки...
... "Ну, ты че дядя выкинь свое барахло, моя супер пупер программа ...." с такими рассуждениями, ничего полезного, а тем более нового, написать неполучится.
Сергей Чикирев
А можно узнать, какого рода программы Вы пишите и на какие рессурсы они ориентированны
С Уважением Сергей Чикирев
Re[4]: А какого хрена идиоты гоняют HTML по сетям?
Здравствуйте, mikkri, Вы писали:
M>Здравствуйте, Nikto, Вы писали:
N>>Здравствуйте, Silver_s, Вы писали:
N>>Ответ на твои вопросы почему очень простой: потому что для таких xml'ек и html'ек были бы нужны специальные редакторы,обычным текстовым тут уже не обойдешься( ты сам в принципе и ответил на вопрос почему). Так вот этот минус перевесил бы все плюсы которые ты перечислил. N>>По поводу "тормозить прогресс": собственно прогресс в области IT заключается в увелечении мощностей компьютеров, сетей и т.п. и, за счет этого, упрощения процесса разработки программ. Чем дальше, тем меньше кого-то волнует какие компы стоят у конечного пользователя или какой у него коннект к инету, главное это скорость разработки...
M>В качестве справки: M>Протокол HTTP допускает сжатие передоваемого контента, к примеру, gzip'ом. Насколько я понимаю, многие браузеры и веб-сервера эту фичу поддерживают. Так что речь о сжатии передаваемых данных, а не хранимых на сервере файликов.
С проксями это не работает, даже ч/з этот сайт... А с его точкой зрения по поводу XML ты тоже согласен?
Re[5]: А какого хрена идиоты гоняют HTML по сетям?
<skipped>
N>С проксями это не работает, даже ч/з этот сайт... А с его точкой зрения по поводу XML ты тоже согласен?
Про сжатие HTTP понятно.
С тем, что сжимать XML полезно — я согласен...
Но здесь принципиальным становится "прозрачность" такого сжатия. Например, сжатие файла средствами NTFS никак не влияет на доступность данного файла для прикладных приложений. Если же XML сжимать явно (как class файлы сжимают в Java при помещении в jar), то существенно сузится удобство применения XML, так как далеко не все программные среды имеют встроенную поддержку сжатия и далеко не все редакторы умеют на лету расжимать и сжимать файлы.
Надеюсь, моя точка зрения понятна .
... << RSDN@Home 1.1 beta 1 >>
Re[5]: А какого хрена идиоты гоняют HTML по сетям?
Здравствуйте, Nikto, Вы писали:
N>С проксями это не работает, даже ч/з этот сайт... А с его точкой зрения по поводу XML ты тоже согласен?
Странно что с проксями не работает. Может просто в IE не поставил галочку
-use HTTP 1.1
и
-use HTTP 1.1 through proxy connections.
Сжатие gzip'ом это еще не бинарный формат, это уловка не от хорошей жизни придуманая.
Да и gzip не максимальное сжатие обеспечивает.
А разработать универсальный двоичный формат можно было бы, да хотябы словарь тегов в XML сделать, а потом битиками их представлять. Это сразу бы как он полегчал. Массивы из сотни одинаковых тегов очень неэффективно в текстовом формате представлены.
А notepad'ом я никогда не пользовался. Чтоб редактировать ручками, хотябы подсветку непомешало бы иметь и автозакрытие тегов, а это уже специальный инструмент.
Re[6]: А какого хрена идиоты гоняют HTML по сетям?
Здравствуйте, 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 а потом транслируют в бинарник.
! А схемы xml, для selfmade-протокола — selfmade validator, надоело. Беда в том, что многие люди начинают относиться к xml, как к панацее, а это в корне неверно, всякая технология имеет свои границы применимости.
Мы уже победили, просто это еще не так заметно...
? 
MB> GQ
дык после второй перезагрузки он продолжел работать как ни вчем не бывало. 
Я даже представить боюсь что надо будет сделать со следующими виндами чтобы они упали и не смоги встать...
.