мне известно, что спецификация CORBA как таковая не допускает различий между IDL, которые использует серверная программа и IDL, который использует клиентская программа.
Однако на практике некоторые различия обязаны работать (довольно) повсеместно, потому что механизм связи, лежащий в основе, скорее всего, представляет собой GIOP (по крайней мере, IIOP), а некоторые различия связаны с невозможно обнаружить с помощью IIOP.
Что я хотел бы установить, так это какие различия разрешены между серверным и клиентским IDL универсально между произвольными ORB, пока используется GIOP/IIOP.
Например: Пока я предполагаю, что это работает для:
- Добавляйте любой тип/интерфейс в серверный IDL при условии, что типы, о которых знает клиентский IDL, не затрагиваются или какие-либо неизвестные новые типы отправляются обратно клиенту.
- Добавьте метод к существующему интерфейсу на стороне сервера — клиент должен иметь возможность продолжать вызывать объекты с этим интерфейсом, даже если его IDL не перечисляет указанный метод. (Кажется, здесь отвечено да.)
- Добавьте элемент в конец перечисления, пока клиент никогда не увидит это новое значение.
- Добавить участника в союз, если клиент никогда не увидит этот тип Union с дискриминатором, установленным на новое значение.
Моя цель состоит в том, чтобы получить что-то вроде краткого списка вещей, которые можно сделать в существующем IDL, чтобы расширить "сервер" новыми элементами без перекомпиляции существующих клиентов с измененным IDL.