Показать сообщение отдельно
Старый 18.03.2010, 14:05   #3  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,894 / 5650 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от gl00mie Посмотреть сообщение
Кажется, публикация прошла незамеченной, хотя она говорит о том, что идея о переходе от интерпретатора в ядре к CLR и к трансляции p-кода в IL живет и здравствует - люди уже вычищают "мелкие несоответствия", замалчивая, правда, более интересные вопросы относительно того, как они перейдут от нынешнего способа взаимодействия клиента и сервера к модели взаимодействия наподобие веб-сервисов.
Нууу - результат - ничто, процесс - все Кроме того они, как я понял, разговоры о веб-сервисах и более stateless подходу к архитектуре отнесли к более отдаленному будущему. Счас-то они похоже что пытаются вместе с аксаптовским p-кодом хранить где-то в определении объекта AOD еще и IL p-code. И соответственно в момент загрузки объекта в память (выполняемого, разумеется, аксаптовским загрузчиком, никаких там assemblies), в зависимости от какого-то параметра грузить объект либо в аксаптовскую виртуальную машину, либо в .netовскую. Учитывая что в Аксапте статических переменных, в чистом виде, нету, а синглетоны можно оставить в Аксаптовской виртуальной машине - подход в целом выглядит реализуемым.
Я, правда, знаю только одно место в Аксапте, где производительность определяется производительностью исполнения p-кода, а не обменом с БД - производственное планирование. И я по прежнему считаю что полноценной миграции системы в .net они не смогут сделать без переписывания всего приложения, а прозрачная для прикладного программиста миграция (при которой просто виртуальная машина подспудно меняется) не очень выгодна по соотношению прирост производительности/затраты на реализацию.