Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 40
Забавно... Надо будет поэкспериментировать
на JSON похоже
А у них и нет цели полностью вытеснить XML. В статье они пишут, что хотели бы такой же хороший инструмент, как XML, но в конкретном случае он не подойдёт из-за производительности. Поэтому они разрабатывают отдельный инструмент под конкретные нужды, и учитывая, кто это - они, у них наверняка получится :)
Поэтому они разрабатывают отдельный инструмент под конкретные нужды, и учитывая, кто это - они, у них наверняка получится :)Они уже уже давно не разрабатывают, а дорабатывают. ProtocolBuffers используются в Google уже не один год. А XML вытеснять они и не думают. ProtocolBuffers позволяют обработать 99% задач - и сделать это быстро. Ну а оставшийся 1% останется на долю XML и прочих методов.
Хорошо бы ещё поддержку PHP и JavaScript сделали.
есть возможность конвертации, скачем .Net объекта в xml представление и назад с минимальными затратами
есть и весьма удобный и в binary тоже есть, только затраты далеко не всегда минимальные... и удобно только если гонять между .NET апликухами... а тут сразу в несколько платформ готовое решение. конечно есть уже куча подобных инструментов, но еще один лишним не будет :D
хмм автор имел ввиду либо .Net Remoting (http://www.rsdn.ru/article/dotnet/inside… ; http://ru.wikipedia.org/wiki/.Net_Remoti…) либо WCF (http://en.wikipedia.org/wiki/Windows_Com… , http://en.csharp-online.net/WCF_Essentia…)
не-не-не :D
я только про сериализацию, которая в .NET весьма удобна но при этом может быть весьма прожорливой а временами даже слишком.
а по поводу непосредственно коммуникации я к конкретным предложениям никогда не привязываюсь т.к. тут выбор обычно диктуется условиями эксплуатации а не ассортиментом готовых решений :")
а фраза «удобно только если гонять между .NET» означает что при попытке передать сериализованный объект на другую платформу обычно возникает гемморой при распаковке(готовых решений нема и т.д.) и в такой ситуации может быть удобнее использовать какое-то компромиссное решение более-менее подходящее под обе взаимодействующие платформы...
З.Ы.: был у меня когда-то неприятный опыт взаимодействия с Flash через ExternalInterface, они там свой XML-based формат для передачи аргументов между контейнером и flash-player'ом использовали. написал сериализатор-десериализатор .NET объекстов в flash'евский формат и он отлично работал за некоторыми исключениями виной которым было несовершенство на тот момент их родного протокола (работа с пустыми строками и т.д.)... в итоге использовал для передачи JSON и был счастлив. вот такой вот компромис :D
я только про сериализацию, которая в .NET весьма удобна но при этом может быть весьма прожорливой а временами даже слишком.
а по поводу непосредственно коммуникации я к конкретным предложениям никогда не привязываюсь т.к. тут выбор обычно диктуется условиями эксплуатации а не ассортиментом готовых решений :")
а фраза «удобно только если гонять между .NET» означает что при попытке передать сериализованный объект на другую платформу обычно возникает гемморой при распаковке(готовых решений нема и т.д.) и в такой ситуации может быть удобнее использовать какое-то компромиссное решение более-менее подходящее под обе взаимодействующие платформы...
З.Ы.: был у меня когда-то неприятный опыт взаимодействия с Flash через ExternalInterface, они там свой XML-based формат для передачи аргументов между контейнером и flash-player'ом использовали. написал сериализатор-десериализатор .NET объекстов в flash'евский формат и он отлично работал за некоторыми исключениями виной которым было несовершенство на тот момент их родного протокола (работа с пустыми строками и т.д.)... в итоге использовал для передачи JSON и был счастлив. вот такой вот компромис :D
хм... XmlSerializer и BinaryFormatter
а по поводу "гонять" , тут уже как кому бог на душу положит, хоть по SMTP/POP3 сериализованные данные отправлять/получать можно
а по поводу "гонять" , тут уже как кому бог на душу положит, хоть по SMTP/POP3 сериализованные данные отправлять/получать можно
Суть то не в технологической инновации. Можно быть уверенным что Google использует это уже лет 10. Это базовая задача которую решали многие компании, но их решения внутри компаний и остаются.
А Google дал разработчикам еще одну хорошую открытую библиотеку.
А Google дал разработчикам еще одну хорошую открытую библиотеку.
Я ведь не утверждал, что все решения остаются внутри, я про AOL.
И причем тут XML. К сожалению автор топика представил, это как альтернативу XML. Но Protocol Buffer это в первую очередь бинарная сериализация, причем кроссплатформенная. Теоретически возможно рассширение и для .net. Возможно и ее сделают.
И причем тут XML. К сожалению автор топика представил, это как альтернативу XML. Но Protocol Buffer это в первую очередь бинарная сериализация, причем кроссплатформенная. Теоретически возможно рассширение и для .net. Возможно и ее сделают.
Всетаки надежность и производительность становится модным. Упрощение структур данных, масштабируемости и скорости разработки за счет фреймворков, и решений представления и обмена данных близкому по смыслу к рассуждению человека плачевны. Все сказывается на производительности и надежности, а конкретно на авторитете программистов - теперь ненужно знать азов языка программирования. Каркасы написаны - строй что хочешь. Лень двигатель прогресса, но и незабудьте и о регрессе. В университете заставляли писать программный код, который реализован был уже давным давно в стандартных библиотеках и функциях, писала вся группа, но при этом подходы решений были разные.
P.S. Никого не решил задеть, помните о спирали жизни. Скорее это напутствие молодым ребятам, не бойтесь становится инженерами. Комментарий вышел ужасный и трудный. :) Текст вылился, жалко удалять.
P.S. Никого не решил задеть, помните о спирали жизни. Скорее это напутствие молодым ребятам, не бойтесь становится инженерами. Комментарий вышел ужасный и трудный. :) Текст вылился, жалко удалять.
Кто напишет первый instant messenger на основе этого протокола?
протокол Hessian с аналогичным назначением давно популярен.
Гугль периодически предлагает общественности какие-то свои странные велосипеды, типа собственной Java Collections Framework :)
Гугль периодически предлагает общественности какие-то свои странные велосипеды, типа собственной Java Collections Framework :)
Hessian - бинарный, а этот новый протокол вполне human-readable.
Пробовали - там многовато ошибок было. Например, он легко сериализованный сложный объект десериализовывал в Map. Смотрели в код - местами было просто не дописано. Хорошо он работает только на относительно простых струкурах данных. Полагаю, Гугл в этом плане был аккуратнее
ProtoBuffer это не аналог XML. Проще воспринимать Protobuffer как способ быстро и эффективоно сохранить на диск данные с последовательным доступом.
Protobuffer это один из столпов Google инфраструктуры, почти все проекты Google используют его. Изучая protobuffer все больше и больше начинаешь восхищаться. В какойто момент познаешь ДАО и писать кипятком от того как гармончно весь конструктор складывается воедино в общую картину.
Теперь ближе к телу. В основном ProtoBuffer используется для логированя. Также используется для RPC, но я не особый знаток этой части, потому расскожу о первой. А для того чтобы вы лучше представляли общую картину - добавим сюда еще несколько вещей:
sawzall - специализированный язык для обработки файлов логов (читай коллекций сериализованных протобуфером)
map-reduce - инфраструктура разбиения задачи на множество маленьких и выполнение их параллельно.
sawmill - собственно большая map-reduce задача для обработки логов.
тулзы для конвертирования XML,YAML,BigTable<->protobuffer
с другой стороны - множество логов от различных сервисов. Например Gmail имеет ~120000 процессов. Каждый процесс пришет в GoogleFileSystem лог файл с именем gmail.20080708.datacenter_id.machine_id.process_id.log различную информацию - кто, откуда, куда кликнул, сколько времени заняло (latency), какие java/javascript ошибки произошли на странице.
И теперь все соедняем. Например нам надо построить график как изменяется напр. latency для браузера IE7 за последние несколько дней c разбиением по версиям gmail (gmail имеет несколько версий в продакшене). Это будет просто - пишем sawzall программу и запускаем ее в sawmill, приговаривая - обработай мне логи сервиса gmail за последние 4 дня. Sawmill запускает несколько копий программы которые параллельно работают над обработкой логов, а затем агрегирует данные.
Точно такую же схему использует Google Analytics для своих целей.
PS Я совсем недавно думал, насчет реализации на Java нечто подобного протобуфер (хотел освежить свои познания в Antlr), но гугл меня опередил. Все что не делается - все к лучшему.
PPS Как видите в use-case котором я описал нет места XML.
PPPS http://research.google.com/pubs/papers.h… вот тут можно найти много интересного чтива.
PPPPS Извиняюсь за кросспост.
Protobuffer это один из столпов Google инфраструктуры, почти все проекты Google используют его. Изучая protobuffer все больше и больше начинаешь восхищаться. В какойто момент познаешь ДАО и писать кипятком от того как гармончно весь конструктор складывается воедино в общую картину.
Теперь ближе к телу. В основном ProtoBuffer используется для логированя. Также используется для RPC, но я не особый знаток этой части, потому расскожу о первой. А для того чтобы вы лучше представляли общую картину - добавим сюда еще несколько вещей:
sawzall - специализированный язык для обработки файлов логов (читай коллекций сериализованных протобуфером)
map-reduce - инфраструктура разбиения задачи на множество маленьких и выполнение их параллельно.
sawmill - собственно большая map-reduce задача для обработки логов.
тулзы для конвертирования XML,YAML,BigTable<->protobuffer
с другой стороны - множество логов от различных сервисов. Например Gmail имеет ~120000 процессов. Каждый процесс пришет в GoogleFileSystem лог файл с именем gmail.20080708.datacenter_id.machine_id.process_id.log различную информацию - кто, откуда, куда кликнул, сколько времени заняло (latency), какие java/javascript ошибки произошли на странице.
И теперь все соедняем. Например нам надо построить график как изменяется напр. latency для браузера IE7 за последние несколько дней c разбиением по версиям gmail (gmail имеет несколько версий в продакшене). Это будет просто - пишем sawzall программу и запускаем ее в sawmill, приговаривая - обработай мне логи сервиса gmail за последние 4 дня. Sawmill запускает несколько копий программы которые параллельно работают над обработкой логов, а затем агрегирует данные.
Точно такую же схему использует Google Analytics для своих целей.
PS Я совсем недавно думал, насчет реализации на Java нечто подобного протобуфер (хотел освежить свои познания в Antlr), но гугл меня опередил. Все что не делается - все к лучшему.
PPS Как видите в use-case котором я описал нет места XML.
PPPS http://research.google.com/pubs/papers.h… вот тут можно найти много интересного чтива.
PPPPS Извиняюсь за кросспост.
Раз уж тема такая, может, кто объяснит - нафига вообще передавать данные в виде XML? Там же будет сплошной ненужный мусор в виде этих самых парных тэгов? И какая разница, что он там хьюман-ридабыл, если все равно всё передаётся, как написано в посте, "между серверами"? Я понимаю, конечно, что в нашем храбром новом мире траффика уже никому не жаль, но всё же...
Натыкался, кстати, на забавную идею использовать как замену XML лисповские S-expressions, т. е. вместо bla-bla-bla будет (one (two bla-bla-bla)), хотя конечно это нафиг никому не нужно, потому что и Лисп устарел, и с читабельностью как-то стрёмно...
Натыкался, кстати, на забавную идею использовать как замену XML лисповские S-expressions, т. е. вместо bla-bla-bla будет (one (two bla-bla-bla)), хотя конечно это нафиг никому не нужно, потому что и Лисп устарел, и с читабельностью как-то стрёмно...
А кто-нибудь, кто разобрался, может объяснить, чем это принципиально отличается от бинарной сериализации объектов, которая, к примеру, используется в .Net, в особенности для Remoting? Там просто пишешь перед классом что-то типа [Serializable], и при компиляции сборки создается такой же быстрый код для записи и чтения полей. Работает, действительно, во многие раз быстрее, чем xml-сериализация.
У меня создалось впечатление, что речь идет не о какой-то революционной технологии, а о стандартной библиотеке сериализации, которыми все давно уже пользуются в разных видах, а Гугл решил просто открыть свою и случайно наделал много шума.
Или я что-то упустил?
У меня создалось впечатление, что речь идет не о какой-то революционной технологии, а о стандартной библиотеке сериализации, которыми все давно уже пользуются в разных видах, а Гугл решил просто открыть свою и случайно наделал много шума.
Или я что-то упустил?
Именно так и есть. Это сериализация от гугла.
Но вроде автор о революции и не пишет. Наверное, люди привыкли ждать от Гугла революций :-)
Но вроде автор о революции и не пишет. Наверное, люди привыкли ждать от Гугла революций :-)
Посути да, это простая сериализация. Только не для специфичного языка/платформы, а для нескольких (скоро будет еще и perl).
Вся мощь protobuffer раскрывается во взаимодействии с другими технологиями Google. Надеюсь гугл скоро и их откроет.
Вся мощь protobuffer раскрывается во взаимодействии с другими технологиями Google. Надеюсь гугл скоро и их откроет.
кросс-платформенность ;)
в плане запаковал в Джаве распаковал в Питоне. мне например очень не хватает возможности удобно(!) гонять сложные структуры между Java и .NET... а писать реализацию BinaryFormatter под Java я пока еще не созрел :"D
за сим очень хочется увидеть ProtoBuffer под .NET, чем и собираюсь занять при первой возможности...
в плане запаковал в Джаве распаковал в Питоне. мне например очень не хватает возможности удобно(!) гонять сложные структуры между Java и .NET... а писать реализацию BinaryFormatter под Java я пока еще не созрел :"D
за сим очень хочется увидеть ProtoBuffer под .NET, чем и собираюсь занять при первой возможности...
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Google Protocol Buffers: альтернатива XML