Не совсем та задача. Задача изначально вот какая: нужно сделать библиотеку, которую на Windows можно использовать из широкого спектра языков. Нужна какая-то волшебная технология, которая позволяет удобно вызывать уже давно написанный и отлаженный код на C++ из C#, VB.Net, разных реализаций C++ и т.д. Для этого есть технология COM. Еще хорошо бы сделать так, чтобы клиентская программа могла быть 64-разрядной и при этом не нужно было переносить весь код на 64 бита. Оказывается, COM+ позволяет решить эту проблему без дополнительных усилий. Все довольны.
Да, 64-битный клиент общается с суррогатным процессом, в котором работает компонент интеграции, а компонент интеграции общается с процессами Recognition Server. Вы можете считать это некрасивым.
Recognition Server — не единственно возможный способ использования технологических библиотек, это продукт для определенной рыночной ниши. Есть сценарии (в других рыночных нишах), когда его инфраструктура вообще не нужна для решаемой клиентом задачи, а этом случае эффективнее использовать другую архитектуру, при которой в процессе клиента работает намного больше кода.
Так что да, вы правы, что в Recognition Server формально 64-битный код нужен не везде, но это не отменяет сценариев, когда формально весь код должен быть 64-битным.
Да, потом внезапно появляется очень дешевая технология производства портативных реактивных снарядов (те самые противотанковые гранатометы), которые с первого попадания делают в броне аккуратное отверстие и убивают экипаж бронированной машины. По-разному же бывает, заранее не угадаешь.
В случае Recognition Server — нет, у него другая архитектура, клиент работает с компонентом интеграции объемом около 100 тысяч строк кода (из них примерно 70 тысяч — код, переиспользуемый во многих подсистемах). Однако ничто не мешает использовать тот же способ интеграции и в случае, когда в одном процессе оказываются два миллиона строк, другой вопрос, что у Recognition Server изначально другая архитектура.
Когда назреет реальная необходимость, это станет реальной проблемой, мы будем решать ее тем способом, который сочтем самым эффективным. Вы сейчас говорите о возможной проблеме неизвестно насколько далекого будущего.
Это не факт, это ваше предположение. Вы запросто можете ошибиться в этом предположении. Вообще речь шла о другом — о том, чтобы не переносить весь код прямо сейчас. Может быть, через какое-то время станет ясно, что код должен быть (N+P)-1 разрядным — вот туда реально и нужно будет переносить, а пока решение с эмуляцией всех устраивает. Мы не тратим время на перенос сейчас, вместо этого тратим его на что-то реально полезное. Fire and Motion ведь как раз об этом.
Вы рискуете сломать палец об небо, в которое постоянно попадаете. Recognition Server — набор отдельных процессов. Код технологических библиотек (распознаватель и все, что рядом) никогда не оказывается в одном процессе с программой клиента даже на 32-битной машине.
Да, вы правы — парк машин с 64-битной Windows растет. Но 32-битные программы на них отлично работают. Какой смысл переносить код на 64 бита, если он нормально работает в режиме эмуляции?
Реальная проблема — как сделать библиотеку так, чтобы ее можно было использовать из 64-битных программ. В случае Recognition Server библиотекой является только компонент интеграции — все остальное в любом случае работает в отдельных процессах, с которыми клиент программно не общается.
Вот тут вы попали пальцем в небо точнее некуда. Recognition Server — набор отдельно работающих процессов, клиенты никогда ни с одним из этих процессов не общаются программно напрямую (только через компонент интеграции). Какая им разница, какая разрядность у тех процессов?
>порядка 270 тестовых конфигураций с разными версиями мускула, постгриса, апача и дистрибутивов никсов, с командой QA, которая в восемь раз превышала команду разработчиков
Большое спасибо за конкретный пример того, как это бывает в реальном мире.
Вот это как раз очень соответствует действительности. Реальных платежеспособных клиентов волнует:
— делает ли библиотека то, что нужно
— работает ли она на их платформе
— легко ли ее интегрировать в программу клиента на выбранном клиентом одном из многих языков.
Представьте себе сколько существует разных операционных систем (в смысле настолько разных, что под каждую нужно делать отдельный дистрибутив).
Нужно будет собирать, тестировать (как следует тестировать) и поставлять дистрибутив под каждую. Вы думаете, это так запросто? Что мы с этого получим кроме ощущения «правильности программирования»?
Те 100500 библиотек обычно приходится пересобирать под конкретную систему. Это не очень удобно, учитывая, что наши продукты не open source и следовательно пересобирать их придется нам.
Код можно перекомпилировать под 64 бита, но он запросто может перестать работать, потому что написание кода без привязки к разрядности требует еще лучшего знания языка и еще большей дисциплины, чем написание просто (не так и просто) хорошего (поддерживаемого, понятного, надежного и эффективно работающего) кода, который компилируется только на 32 бита. Вот примеры.
Некоторые проблемы такого вида можно выявить только после очень тщательного тестирования. Плюс есть очень много старого (зато работающего и проверенного) кода, при написании которого 64 бита были как сферический конь в вакууме. Соответственно, если у вас есть неограниченное число разработчиков и тестировщиков с неограниченно высокой квалификацией, то это вовсе не проблема. В реальном мире ресурсы очень ограничены.
Даже интересно. Вдруг мы правда заняты не тем… Есть ссылка на описание того, как конкретно написать библиотеку, чтобы можно было использовать ее из-под всего и везде?
POSIX… Это стандарт интерфейса операционной системы?
Клиентская программа как-то общается с библиотекой, а библиотека как-то общается с операционной системой. POSIX — стандарт общения с операционной системой, общение программы с библиотекой тут ни при чем.
«По-хорошему» звучит прочто отлично. Но что за этим стоит? Ощущение, что использована «правильная, достойная технология»? Хорошо, но бессмысленно. Никого не волнует, что там внутри, пока оно нормально работает. Переписывать на очередную «правильную и достойную» можно так долго, что к окончанию процесса она уже окажется «старой и немодной» и надо будет переписывать дальше.
Recognition Server — не единственно возможный способ использования технологических библиотек, это продукт для определенной рыночной ниши. Есть сценарии (в других рыночных нишах), когда его инфраструктура вообще не нужна для решаемой клиентом задачи, а этом случае эффективнее использовать другую архитектуру, при которой в процессе клиента работает намного больше кода.
Так что да, вы правы, что в Recognition Server формально 64-битный код нужен не везде, но это не отменяет сценариев, когда формально весь код должен быть 64-битным.
Реальная проблема — как сделать библиотеку так, чтобы ее можно было использовать из 64-битных программ. В случае Recognition Server библиотекой является только компонент интеграции — все остальное в любом случае работает в отдельных процессах, с которыми клиент программно не общается.
Большое спасибо за конкретный пример того, как это бывает в реальном мире.
— делает ли библиотека то, что нужно
— работает ли она на их платформе
— легко ли ее интегрировать в программу клиента на выбранном клиентом одном из многих языков.
Нужно будет собирать, тестировать (как следует тестировать) и поставлять дистрибутив под каждую. Вы думаете, это так запросто? Что мы с этого получим кроме ощущения «правильности программирования»?
Некоторые проблемы такого вида можно выявить только после очень тщательного тестирования. Плюс есть очень много старого (зато работающего и проверенного) кода, при написании которого 64 бита были как сферический конь в вакууме. Соответственно, если у вас есть неограниченное число разработчиков и тестировщиков с неограниченно высокой квалификацией, то это вовсе не проблема. В реальном мире ресурсы очень ограничены.
Вопросы на собеседованиях очень простые. Отличить человека, который может писать хороший код на С++, можно без выяснения тонкостей написания кода без привязки к разрядности. В конце концов, описание наиболее типичных проблем можно найти Гуглом за 10 минут.
Семинары есть, на них происходит обмен опытом по разным специфическим проблемам. Например, опытом разработки распределенных программ.
Клиентская программа как-то общается с библиотекой, а библиотека как-то общается с операционной системой. POSIX — стандарт общения с операционной системой, общение программы с библиотекой тут ни при чем.