LINUX.ORG.RU

Google открыла свою IDL-библиотеку — Protocol Buffers

 ,


0

0

Google открыла под лицензией Apache свою реализацию IDL — Protocol Buffers. Эта библиотека позволяет описывать структуры данных на специальном языке, который потом компилируется в код C++, Java или Python. Скомпилированный код включает оптимизированные методы сериализации и десериализации структур, а также методы get и set для каждого поля.

Специально подчеркивается, что в отличие от прочих IDL, Protocol Buffers отличается простотой и эффективностью.

Сайт проекта: http://code.google.com/p/protobuf/

>>> Анонс

>Специально подчеркивается, что в отличие от прочих IDL, Protocol Buffers отличается простотой и эффективностью.

ну это все пишут.

Tails
()

Ну что, ждем когда это портируют в dbus.

aiker ★★
()

Прочитал как устроен, прикольно! Действительно - эффективней чем xml.

Ps хотел сам запостить - опередили :)

PPS http://www.lenta.ru/news/2008/07/08/google/

fi ★★★
()

У гугля все хорошо, но иногда они перестаю замечать собственные ошибки.
На странице документации приведен пример показывающий на сколько формат
эффективен и тут же допускают ошибку... то что они записали как 

<person>
  <name>John Doe</name>
  <email>jdoe@example.com</email>
</person>

следовало вообще-то записывать как

<person name="John Doe" email="jdoe@example.com" />

кстати получается и оптимальнее чем их текстовая запись и с адресацией не так геморойно =)

Хотя сам формат описания формата данных весьма интересен и прост, в отличии от...

RSM
()

хуйня заключается в том, что это либа не состыкуется с их с++ кодестайлом: из их туториала: inline const ::std::string& name() const; inline void set_name(const ::std::string& value);

но все мы прекрасно знаем, что конструктор std::string'а может кидать исключение.

sni4ok
()
Ответ на: комментарий от sni4ok

кретин, они не используют исключений

anonymous
()

мне одному кажется, что они велосипед изобрели ?
Чем им уже существующий JSON не угодил, под который уже есть куча софта (парсеров и т.д) ?
В принципе похоже это тоже самое, с некоторыми косметическими изменениями.

anonymous
()

Чем это лучше такого:

   public void writeObjects() throws FileNotFoundException, IOException {
      FileOutputStream fos = new FileOutputStream(fileName);
      GZIPOutputStream gzos = new GZIPOutputStream(fos);
      ObjectOutputStream oos = new ObjectOutputStream(gzos);
      oos.writeDouble(someValue);
      oos.writeObject(someString);
      oos.writeObject(someObject);
      oos.close();
   }

   public void readObjects() throws FileNotFoundException, IOException, ClassNotFoundException {
      FileInputStream fis = new FileInputStream(fileName);
      GZIPInputStream gzis = new GZIPInputStream(fis);
      ObjectInputStream ois = new ObjectInputStream(gzis);
      someValue = ois.readDouble();
      someString = (String) ois.readObject();
      someObject = ois.readObject();
      ois.close();
   }

???

iZEN ★★★★★
()

Буфера рулят по умолчанию. Раввинат одобряет.

Gharik
()
Ответ на: комментарий от anonymous

> Чем им уже существующий JSON не угодил

JSON сложно проверять на логические ошибки в структуре как при записи, так и при чтении.

ximeric
()
Ответ на: комментарий от anonymous

Мне кажется, что они даже велосипед не осилили, ну может быть трехколесный. Просто детский сад какой-то. Больше напоминает студенческую курсовую работу, чем продукт ведущей интернет компании.

anonymous
()
Ответ на: комментарий от anonymous

> Чем им уже существующий JSON не угодил, под который уже есть куча софта (парсеров и т.д) ?

существенно большим обьемом траффика.

szh ★★★★
()
Ответ на: комментарий от anonymous

> мне одному кажется, что они велосипед изобрели ? > Чем им уже существующий JSON не угодил, под который уже есть куча софта (парсеров и т.д) ? > В принципе похоже это тоже самое, с некоторыми косметическими изменениями.

JSON это готовый формат. Не очень компактый и сложно валидируемый. А "это" - заготовка по которой отливаются классы и структуры, оптимизированная для коммуникации - вроде можно и в ХМЛ и в бинарь сериализовать.

Но ИМХО самое нужное из этого то, что автоматически сгенеренный Java-класс легко и без ошибок десериализуется на C++ или Python. Дальше они уже затачиваются под сериалайз одной версией, а десериалайз другой версией класса. Это нужно в малом количестве проектов, но в энтерпрайз 24/7 без такого лисапеда никуда, ибо нельзя отключать систему, а потому при апгрейде кластер какое-то время работает в гибридном режиме. Вот заточка под поддержку гибридности и анонсирована на сайте.

Респект Google :)

VoDA ★★
()

>>>>Protocol Buffers отличается простотой и эффективностью.

Птица Говорун отличается умом и сообразительностью, умом и сообразительностью, умом и......

anonymous
()
Ответ на: комментарий от sv75

Zeroc ICE - это альтернатива Corba... А у них простая сериализация? Или я где-то что-то не дочитал?

anonymous
()

Так же Protocol Buffers отличается от XML тем, что там не декларируется что его может читать и править человек. IMHO вполне логичное развитие XML.

В общем долой XMLные конфиги, а для обмена между програмами пусть будет Protocol Buffers.

Evgueni ★★★★★
()
Ответ на: комментарий от anonymous

> В отношении Си++ это простой велосипед. Boost.Serialization наше все.

А вы сами это чудо использовали?

anonymous
()
Ответ на: комментарий от Evgueni

>В общем долой XMLные конфиги

ждем geek'а

anonymous
()

Erlang

Там давно искаропки.

anonymous
()
Ответ на: комментарий от anonymous

>Почитал обсуждение, там про ASN.1 никто не вспомнил.

Ага, есть десятый закон Гринспуна -- "Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp."

Потом появился десятый закон Армстронга -- "why implement half of Erlang in a bug-ridden fashion in some other language, when you can get the real thing?"

Теперь пора вводить десятый закон Лампорта -- "Any sufficiently complicated home grown serialization/deserialization framework contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of ASN.1"

>ASN.1 R.I.P.?

Как раз популяризация таких вот библиотек и приближает момент "ASN.1 R.I.P."

Хотя сами ASN.1-овцы пока говорят, что слухи об их смерти несколько преувеличены: http://asn1.elibel.tm.fr/en/introduction/myths.htm

eao197 ★★★★★
()

Наши велосипеды - самые велосипедистые

Чую, гугль перенимает стратегию успеха у яббла. Тот же оголтелый пиер, доходящий до религиозного фанатизма, те же толпы красноглазых фанбоев. Выкинут никому не нужный высер, а шуму-то!

А сабжевая поделка попросту не нужна, ибо давным-давно есть Thrift, опробованный и стабильный, c привязками для C++, C#, Java, Perl, Python, PHP, Erlang, Ruby, OCaml, Haskell и т. д.

http://en.wikipedia.org/wiki/Thrift_(protocol)

http://wiki.apache.org/thrift/

anonymous
()
Ответ на: Наши велосипеды - самые велосипедистые от anonymous

Чую, гугль перенимает стратегию успеха у яббла. Тот же оголтелый пиер, доходящий до религиозного фанатизма, те же толпы красноглазых фанбоев. Выкинут никому не нужный высер, а шуму-то!

А сабжевая поделка попросту не нужна, ибо давным-давно есть ASN.1, опробованный и стабильный, c привязками для C, C++, C#, Java, Delphi, COBOL, Perl, Python, PHP, Erlang, Ruby, OCaml, Haskell и т. д.

http://ru.wikipedia.org/wiki/ASN.1

http://asn1.elibel.tm.fr/en/

anonymous
()

Афигеть, я года два как такое на Perle для C++ накатал. Все мысли крадут :-). Где-то утечка!

Из вот такого:
CLASS CSetup CMessageBase ~ Это класс инициирующий соединение                             
 NAME SETUP                                                                               
# HEADER ../../dgwlib/include/media.h                                                     
 ENUM ECALLTYPE ~ Енум                                                                    
  e_BASECALL 10 ~ базовый вызов                                                           
  e_REVERTCALL ~ none                                                                     
 ~                                                                                        
 ITEM m_cid unsigned short ~ Идентификатор соединения к которому относится сообщение      
 ITEM m_mid unsigned short                                                                
 ITEM m_src std::string                                                                   
 ITEM m_dst std::string                                                                   
 ITEM? m_calltype ECALLTYPE                                                               
 VECTORITEM m_line unsigned char ~ массив типов                                           
 CONSTFUNC bool IsUnid void                                                               
  return (m_cid.Value()&0x8000)!=0;                                                       
 ~                                                                                        
 FUNC void CID unsigned short __cid ~ Установка идентификатора                            
  m_cid.Set(__cid);                                                                       
 ~                                                                                        
~  

типа такое генерю:
/*! @brief Это класс инициирующий соединение */                                           
class CSetup:public CMessageBase                                                          
{                                                                                         
 public:                                                                                  
 /*! @brief Енум */                                                                       
  enum ECALLTYPE                                                                          
  {                                                                                       
   e_BASECALL=10, /*!< @brief базовый вызов */                                            
   e_REVERTCALL /*!< @brief none */                                                       
  }; /* ECALLTYPE */                                                                      
                                                                                          
 public:                                                                                  
  CComponent<unsigned short>     m_cid;      /*!< @brief Идентификатор соединения к которо
  CComponent<unsigned short>     m_mid;                                                   
  CComponent<std::string>        m_src;                                                   
  CComponent<std::string>        m_dst;                                                   
  CComponent<ECALLTYPE,false>    m_calltype;                                              
  CComponentArray<unsigned char> m_line;     /*!< @brief массив типов */                  
                                                                                          
 public:                                                                                  
  static CMessageBase::msgtypes_t StaticType( void ) {return DEF_STATICTYPE_CSETUP;}      
                                                                                          
  CSetup( void )                                                                          
  :CMessageBase( StaticType(),"SETUP",                                                    
   _SRegistrator() << m_cid << m_mid << m_src << m_dst << m_calltype << m_line ) {}       
                                                                                          
  bool IsUnid( void ) const                                                               
  {                                                                                       
   return (m_cid.Value()&0x8000)!=0;                                                      
  }; /* IsUnid */                                                                         
                                                                                          
  /*! @brief Установка идентификатора */                                                  
  void CID( unsigned short __cid )                                                        
  {                                                                                       
   m_cid.Set(__cid);                                                                      
  }; /* CID */                                                                            
                                                                                          
}; /* CSetup */                                                                           

alx_me ★★☆
()
Ответ на: комментарий от anonymous

Спасибо ASN вместе BNF идут.... Такое генерят, что страшно пользоваться обычному человеку. Хочеться чего-то простого, своего. Хотя конечно вы где-то правы, стандарт всё-таки, надо подумать.

alx_me ★★☆
()
Ответ на: комментарий от alx_me

В моем собственном велосипеде, которым я пользуюсь уже
почти шесть лет, твой пример выглядел бы так:

// Просто пишется руками...
class CSetup : public CMessageBase {
  OESS_SERIALIZER( CSetup )
 public:                                                                                  
  ... объявление enum-ов, конструкторов, методов и пр...

 private:
  unsigned short m_cid;
  unsigned short m_mid;
  std::string m_src;
  std::string m_dst;
  int m_calltype;
  std::vector< unsigned char > m_line;
};

Затем к нему добавляется DDL-файл:

{type CSetup {super CMessageBase}
  {attr m_cid {of oess_1::ushort_t}}
  {attr m_mid {of oess_1::ushort_t}}
  {attr m_src {of std::string}}
  {attr m_dst {of std::string}}
  {attr m_calltype {of oess_1::int_t}
    {default {c++ CSetup::e_BASECALL}
      {present_if {c++ m_calltype != CSetup::e_BASECALL }}
    }
  }
  {attr m_line {stl-vector} {of oess_1::uchar_t}}
}

Если же требуется, чтобы в будущем CSetup можно было расширять
новыми полями, то в DDL-описание нужно добавить еще одну строку:

{type CSetup {super CMessageBase}
  {extensible}
  ...
}

Так что дело лисапедостроителей цветет и пахнет не только в Google :)

PS. Когда я делал свой велосипед, то об ASN.1 не знал. Если бы знал,
не делал бы.

eao197 ★★★★★
()
Ответ на: комментарий от anonymous

2 anonymous (*) (08.07.2008 21:39:54):

При их записи name и email вкачестве отдельных тегов предполагается возможность появления нескольких name и email (по крайней мере не ограничивается форматом), при использовании же аттрибутов - это будет соответствовать их же структуре Person{}, где name и email предусмотрены в единственном экземпляре.

RSM
()
Ответ на: комментарий от anonymous

> По-момему, вы не совсем поняли, чем Google Protocol Buffers отличается от навороченных Zerc и Thrift...

Тем, что умеет меньше?

anonymous
()
Ответ на: комментарий от anonymous

>А вы сами это чудо использовали?

Да.

Гугол продает свой бизнес и начинает заниматься производством двухколесных лисапедов. )

anonymous
()
Ответ на: комментарий от RSM

>При их записи name и email вкачестве отдельных тегов предполагается возможность появления нескольких name и email (по крайней мере не ограничивается форматом), при использовании же аттрибутов - это будет соответствовать их же структуре Person{}, где name и email предусмотрены в единственном экземпляре.

Получается, два имейла - стронгли прохибитед для персона? Интересная айдия.

Dimentiy ★★
()
Ответ на: комментарий от eao197

Да фиг там, пока живы openssl-ы, snmp-ы и прочие сетевые протоколы активно использующие ASN.1, тот не рип никогда, плюс у ASN есть xml вариация. А по теме - ну написали еще один вариант сериализации, ну и хрен с ним )))

PETER ★★
()
Ответ на: комментарий от PETER

Вы наверно не поняли. Они используют Protocol Buffers для хранения данных на собственных сервера и RPC! И доступ к своим сервисам они намерены предоставлять тоже с использованием RPC на Protocol Buffers, что и проще и значительно экономичнее с точки зрения ресурсов их серверов (по сравнению с "openssl-ы, snmp-ы... ASN,1" и т.п.). Это просто соглашения по вызову их API. И никуда Вы не денетесь - будете его использовать, если захотите использоваться их сервисами!

А пользоваться таким "велосипедом" действительно удобнее, особенно с учетом его масштабирования. Проверено на собственном опыте и собственном велосипеде.

anonymous
()
Ответ на: комментарий от Dimentiy

> Получается, два имейла - стронгли прохибитед для персона?

Я говорю исключительно про пример от гугля. В их описании message Person{} так же предполагается только один мыл, а вот PhoneNumber в примере множественен, его в XML следует представлять тегами. Впрочем видимо по ссылке сходить не судьба и посмотреть о чем речь =)

RSM
()

Гугль - ненужен. а Apache-licensed софт - тем более. включая сам апач, безусловно.

BasileyOne
()
Ответ на: комментарий от anonymous

> А пользоваться таким "велосипедом" действительно удобнее, особенно с учетом его масштабирования.

О каком масштабированнии данного велосипеда идет речь?

eao197 ★★★★★
()
Ответ на: комментарий от RSM

>Впрочем видимо по ссылке сходить не судьба и посмотреть о чем речь =)

Спасибо, почитал. Видимо да, по одному гмейлу в руки.
p.s. "uniquely numbered fields" - очень удобно в использовании, ага.

Dimentiy ★★
()
Ответ на: комментарий от eao197

>О каком масштабированнии данного велосипеда идет речь?

Почитайте описание... можно расширять messages не теряя совместимости... Будут читаться старые данные новой версией, а при желании и новые данные старой версией программы...

anonymous
()
Ответ на: комментарий от Dimentiy

>p.s. "uniquely numbered fields" - очень удобно в использовании, ага.

Опять же, читайте описание - это для внутреннего представления а не для использования программистом. Для того, чтобы "расширеная" версия message была обратно совместима со старой.

Для использования программистом предлагаются property-s в обертках... или Get Set методы если пишете на Ц++

anonymous
()
Ответ на: комментарий от anonymous

>>О каком масштабированнии данного велосипеда идет речь?

>Почитайте описание... можно расширять messages не теряя совместимости... Будут читаться старые данные новой версией, а при желании и новые данные старой версией программы...

Какое же это масштабирование? Это обычное расширение или другими словами поддержка эволюции схемы данных. В ASN.1 уже давным давно существуют для этих целей т.н. extension points -- специальные обозначения в ASN.1-спецификациях, которые указывают где данный тип может быть расширен в будущем.

eao197 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.