не совсем так — фонетические алфавиты есть и у некоторых диалектов (хотя бы упоминаемый в статье ютпхин для кантонского).
но зачем поддерживать в единой стране такой языковой сепаратизм?
Мы пока присматриваемся к рынку устройств на Андроид, в конце года планируется выход первого продукта под эту платформу. И быть ли Lingvo на Андроиде, зависит от этого опыта.
Не совсем. В случае Recognition Server в процессе клиента работает максимум компонент интеграции, а весь остальной код (которого много строк) — в отдельных процессах. Вопрос был о другом сценарии — когда отдельных процессов изначально нет и все много строк загружаются в процесс клиента. Как предлагаемое решение позволит во втором случае не переносить все много строк на 64 бита?
Еще — как это работает в сценарии, когда все много строк кода изначально работали в процессе клиента? Все равно же нужно будет где-то провести межпроцессную границу и организовать взаимодействие, верно?
Не совсем та задача. Задача изначально вот какая: нужно сделать библиотеку, которую на 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, которая в восемь раз превышала команду разработчиков
Большое спасибо за конкретный пример того, как это бывает в реальном мире.
Вот это как раз очень соответствует действительности. Реальных платежеспособных клиентов волнует:
— делает ли библиотека то, что нужно
— работает ли она на их платформе
— легко ли ее интегрировать в программу клиента на выбранном клиентом одном из многих языков.
но зачем поддерживать в единой стране такой языковой сепаратизм?
правда, зная китайцев, думается, что пойдет — рано или поздно.
Да, идея интересная, нужно будет ее внимательно оценить. Спасибо.
Объективно это выглядит как то же самое, но по-другому, нужно будет внимательно оценить слабые и сильные стороны.
«Экспертно»-субъективно — это «очередные грабли и феерические костыли, чтобы только не проектировать приложение нормально с самого начала».
Это интересно. Где можно узнать больше?
Еще — как это работает в сценарии, когда все много строк кода изначально работали в процессе клиента? Все равно же нужно будет где-то провести межпроцессную границу и организовать взаимодействие, верно?
Recognition Server — не единственно возможный способ использования технологических библиотек, это продукт для определенной рыночной ниши. Есть сценарии (в других рыночных нишах), когда его инфраструктура вообще не нужна для решаемой клиентом задачи, а этом случае эффективнее использовать другую архитектуру, при которой в процессе клиента работает намного больше кода.
Так что да, вы правы, что в Recognition Server формально 64-битный код нужен не везде, но это не отменяет сценариев, когда формально весь код должен быть 64-битным.
Реальная проблема — как сделать библиотеку так, чтобы ее можно было использовать из 64-битных программ. В случае Recognition Server библиотекой является только компонент интеграции — все остальное в любом случае работает в отдельных процессах, с которыми клиент программно не общается.
Большое спасибо за конкретный пример того, как это бывает в реальном мире.
— делает ли библиотека то, что нужно
— работает ли она на их платформе
— легко ли ее интегрировать в программу клиента на выбранном клиентом одном из многих языков.