-Музыка

 -Подписка по e-mail

 

 -Поиск по дневнику

Поиск сообщений в Flashr

 -Статистика

Статистика LiveInternet.ru: показано количество хитов и посетителей
Создан: 26.02.2007
Записей:
Комментариев:
Написано: 6574


Мысль про Google и вебмастеров.

+ в цитатник

Cообщение скрыто для удобства комментирования.
Прочитать сообщение


QoSyS   обратиться по имени Среда, 09 Июля 2008 г. 01:20 (ссылка)
С технологической точки зрения, как я считаю - Protocol buffers лучше читается, и если уж верить факу Гугла - его апи намного проще обычного DOM xml-вского. Так что вполне-вполне, и протокол может себя оправдать :)

Если стандартизируют формат - тогда уже можно будет говорить о происках гугла в "не нуждающихся в замене вещах" )
Ответить С цитатой В цитатник
Перейти к дневнику

Среда, 09 Июля 2008 г. 15:05ссылка
и если уж верить факу Гугла - его апи намного проще обычного DOM xml-вского.

Опять 25, откуда пошло сравнение API и XML? А тем более DOM - это модель работы с XML. Просто у вебмастеров, которые привыкли передавать данные (объекты) в виде xml в вызовах по Ajax или еще где, долго и нужно разбирают потом полученные данные средствами того же DOM. Вот у них и накопилась злоба на XML в целом. Но XML это просто формат записи данных. Это может быть строчка, может быть число, может быть объект, который сам из себя содержит еще кучу других данных. По XML можно при желаниии выстроить объект определенного класса, что в .Net не составляет труда.
Перейти к дневнику

Среда, 09 Июля 2008 г. 18:04ссылка
Я говорил про конкретную реализацию api на базе модели DOM-a. В данном случае - это, как я понимаю, в .NET. Тем более, с учетом всего этого обычно реализовано две модели DOM и SAX. Притом если SAX - это модель и апи вместе, то было бы не логично говорить о том что DOM - это только модель.

Заметь, а сравнивать api c xml начал ты, а не я. У меня явно указано "api обычного DOM-а " Так что нечего руками махать :)

По XML можно при желаниии выстроить объект определенного класса, что в .Net не составляет труда.

Я бы сказал, что в майкрософтской платформе это немного реализовано через ж-пу. Ибо, в данном случае идет неконтролируемая сериализация объектов, и малейшее отклонение ведет к полному провалу. Можно очень надеятся, что, Protocol Buffers наполнят еще дополнительным тулкитом для контроля таких случайностей.
Перейти к дневнику

Среда, 09 Июля 2008 г. 19:24ссылка
Зачем тебе контролировать то, что должно работать без твоего ведома. SOAP вызовы в реализации .Net работают с сериализацией достаточно успешно и ниразу не было необходимоти что-то там конролировать.
Перейти к дневнику

Среда, 09 Июля 2008 г. 19:54ссылка
Иногда полезно иметь такой функционал. Мы уже серьезно отошли от самого вопроса.

На странице описания Protocol Buffers есть пункт, почему лучше использовать именно этот формат. Глянь.

И когда программируешь, все-таки проще написать :
cout << "Name: " << person.name() << endl;
cout << "E-mail: " << person.email() << endl;
Перейти к дневнику

Четверг, 10 Июля 2008 г. 00:24ссылка
Могу заверить, что я прочитал этот топик прежде чем комментировать.
Вот как это должно выглядит у людей:
--------
MyObject person = XmlSerializer.Decode(input.data);

this.TextBox1.text = "Name " + person.name + "; E-mail: "+ person.email;
--------
В случае обработки SOAP вызова я даже париться с декоде не буду, а в объявлении класса MyObject напишу [(Serializiable)] - все равно что объявление гугловских файлов ".proto"


-------
PS: из их текста, на который ты ссылаешься, они эти свои плюсы приводят криво сравнивая DOM XML и их API, сразу вижно, что автор не работал с .Net
 

Добавить комментарий:
Текст комментария: смайлики

Проверка орфографии: (найти ошибки)

Прикрепить картинку:

 Переводить URL в ссылку
 Подписаться на комментарии
 Подписать картинку