Придется конкурировать с Google? ;)

Вчера обнаружил, что Google выпустил еще один OpenSource продукт, который является конкурентом одной из моих разработок. Похоже, назревает время серьезной конкуренции с Google :))) Ну да по порядку.

Вначале появился проект Google Protocol Buffers -- это инструмент для сериализации/десериализации данных, который на данный момент поддерживает языки C++, Java и Python. Принцип работы Protocol Buffers достаточно прост: на специальном языке программист описывает структуры своих данных, например:

message Person {
  required string name = 1;
  required int32 id = 2;
  optional string email = 3;

  enum PhoneType {
    MOBILE = 0;
    HOME = 1;
    WORK = 2;
  }

  message PhoneNumber {
    required string number = 1;
    optional PhoneType type = 2 [default = HOME];
  }

  repeated PhoneNumber phone = 4;
}

после чего из этого описания генерируется вспомогательный код, который отвечает за сериализацию/десериализацию объектов этого типа в программе:

Person person;
person.set_name("John Doe");
person.set_id(1234);
person.set_email("jdoe@example.com");
fstream output("myfile", ios::out | ios::binary);
person.SerializeToOstream(&output);

fstream input("myfile", ios::in | ios::binary);
Person person;
person.ParseFromIstream(&input);
cout << "Name: " << person.name() << endl;
cout << "E-mail: " << person.email() << endl;

При этом поддерживается расширение сериализуемых типов в последствии (изменение типов полей, добавление полей).

Google не изобрел ничего нового. Подобные инструменты (и даже более мощные, на мой взгляд) уже давно существовали. Начать можно с ASN.1 -- большой стандарт, который определяет несколько способов упаковки данных (называемых encoding rules: двоичный BER (он же TLV -- Tag-Length-Value), двоичный PER (где данные могут упаковываться с плотностью до бита), XML-ный XER), а так же имеет специальное понятие extension points (т.е. мест в описании структур данных, в которых будущие версии могут содержать дополнения). С другой стороны, изучение ASN.1 не простая штука. Да и инструментарий для поддержки ASN.1, как правило, платный. И, в дополнение к этому, отображение ASN.1 на конкретный язык программирования не стандартизировано. Поэтому, выбор ASN.1-компилятора автоматически означает привязку разработчика к одному поставщику ASN.1-инструментария.

Другим конкурентом Protocol Buffers является Thrift, который начинался внутри проекта Facebook, а сейчас он включен в Apache Incubator. Небольшое сравнение между возможностями Thrift и Protocol Buffers можно увидеть здесь.

Так же можно вспомнить знаменитые проекты для C++ сериализации: Boost.Serialization и s11n.

Ну и мой проект ObjESSty предназначен для тех же целей, что и Protocol Buffers. ObjESSty, в отличии от Protocol Buffers, сейчас ориентирован исключительно на C++. Но зато для C++ ObjESSty имеет встроенную поддержку множественного наследования и стандартных STL-контейнеров (list, set, map, vector). А главной фишкой ObjESSty является поддержка атрибутов-указателей и наследования расширением (subclassing by extension).

Для меня стало сюрпризом то, какой восторг поднялся на программистских форумах по поводу Google Protocol Buffers. Уж не знаю, что здесь сыграло главную роль: бренд Google, заставляющий писать кипятком, или удачное сочетание в Protocol Buffers простоты и мощности инструмента.

Вторым конкурентом со стороны Google для меня оказался проект Software Construction Toolkit -- грубо говоря, очередной build tool для C++. Написанный на Python и построенный на основе SCons. Т.е. полку конкурентов моего Mxx_ru прибыло.

Не знаю, какой шум по поводу swtoolkit поднимется сейчас. Может быть, опять громкое имя Google сработает. А может быть ничего и не произойдет -- не смотря на длительное время существования того же SCons и ряда альтернативных build tool-ов (CMake, Bakefile, Boost Build, Rake, qmake, Ant) ни один из них пока не занял доминирующего положения и не вытеснил традиционный make (который под Unix-ом дополняется набором autotools) и проектные файлы конкретных IDE (то бишь, Visual C++ под Windows).

Уж не знаю, какие перспективы будут у Mxx_ru. С мыслью о том, что Mxx_ru станет сколько-нибудь заметным инструментом, я давно распрощался. Во-первых, это требует серьезного пиара и проталкивания Mxx_ru в различных англоязычных форумах и новостных группах. Во-вторых, Mxx_ru требует еще больших вложений -- нужны новые фичи, поддержка новых платформ, дополнительная документация и пр. На что требуются силы и время. А с этим не так просто. В первую очередь потому, что на данный момент Mxx_ru практически полностью удовлетворяет мои потребности. И поэтому Mxx_ru сейчас находится в той стадии, когда он дорабатывается только когда мне или кому-нибудь из пользователей Mxx_ru что-то понадобится и пожелание к Mxx_ru будет сформулировано и озвучено. Например, благодаря такому пожеланию в Mxx_ru недавно была добавлена поддержка Qt4. Может быть, какие-то новые изменения ждут Mxx_ru после появления нормальных стабильных версий Ruby 1.9 (даже в недавно вышедшем 1.9.1 я выловил баг, не позволяющий перевести под 1.9 один из моих Ruby-проектов). Есть надежда, что под Ruby 1.9 Mxx_ru будет работать быстрее. И что под Ruby 1.9 будет проще реализовать многопоточную сборку проекта (чтобы задействовать мощности современных многоядерных процессоров).

Пока же с удовольствием могу отметить, что документация по Mxx_ru, на мой взгляд, гораздо лучше таковой для swtoolkit. Даже странно -- вроде бы большая контора Google, могли бы найти ресурсы на выпуск хорошей документации для swtoolkit. Так что, есть смысл побороться с Google! ;)