Аналог COM в Linux

[Юрій Ткаченко]

У мене сьогодні виникло запитання: а чи існує у Linux аналог технологій MS COM/OLE?
Колись давно я чув про якусь інтеграцію GNOME та CORBA, але якось цим не цікавився. А зараз стало цікаво (подумав, що замість інтерфейсів SWIG для різних мов програмування можна було б зробити один загальний). Хто що може про це сказати?

[Володимир Лісівка]

Є відразу три аналоги:
Gnome: Bonobo
Mozila: XPCOM
KDE: KParts

Але вони призначені лише для GUI.

Робити загальносистемний COM, CORBA чи RPC інтерфейс до всіх системних бібліотек мабуть немає сенсу - така реалізація буде значно повільніша (на практиці - в 5-10 раз) за реалізацію на прямих викликах.

Можливо легше стане, коли більше бібліотек портують на Яву - там такої проблеми нема, будь-який клас можна проаналізувати під час виконання.

[Yaroslav Fedevych]

А чим воно функціонально краще за конвеєри?

[Анатолій Сахнік]

Колись давно я чув про якусь інтеграцію GNOME та CORBA, але якось цим не цікавився.

Наскільки мені відомо, немає загальносистемної реалізації моделі об’єктних компонентів у Юнікс. Тим більше нічого не можна знайти про згадувану в MSDN "COM for unix". Проте є різні реалізації CORBA, найбільш цікавою з яких я вважаю ACE::TAO. До набору інструментів розробника Відкритого Офісу входить дуже розвинена бібліотека UNO (Universal Network Objects). Обидві названі мають спільну рису крім безкоштовності: переносність на різні платформи.

[Сергій Кудрик]

У ближчому майбутьному KDE та GOME перейдуть
 на один IPC -   D-BUS.

http://www.freedesktop.org/wiki/Software_2fdbus

[Юрій Ткаченко]

Конкретизую питання.
Мені довелося займатися тривіальною для пострадянських часів задачею - підключення торгового обладнання до комп'ютера (з Windows, звичайно   ). Драйвер  я зробив у вигляді COM-об'єкта. Це дало змогу користуватися ним відразу і без проблем з MS Office, 1C...
Після цього я подумав: а як це могло б виглядати в Linux?
Схоже питання я знайшов тут:
http://slashdot.org/article.pl?sid=00/10/20/2259228&mode=thread
Але після цього вже пройшло багато часу. Думав, що можливо щось змінилося. Та схоже на те, що ні.
В принципі, SWIG - це зараз мабуть найкращий спосіб взаємодії скриптів з бібліотеками на C/C++ в Linux.

[Володимир Лісівка]

Конкретизую питання.
Мені довелося займатися тривіальною для пострадянських часів задачею - підключення торгового обладнання до комп'ютера (з Windows, звичайно   ). Драйвер  я зробив у вигляді COM-об'єкта. Це дало змогу користуватися ним відразу і без проблем з MS Office, 1C...
Після цього я подумав: а як це могло б виглядати в Linux?

Зараз у Лінуксу напевно треба робити бібліотеку на Сі та лакти чи плагіни до програм, які мали б її використовувати. :-(

Можливо з часом Ява (яка чудово компілюється gcc-кою і може бути зінтегрована напевно з будь-якою мовою) стане таким стандартом - тоді будь-яку скомпільовану gcc-кою явовську бібліотеку можна буде викликати напряму з інтерпретаторів приблизно так само як в JavaScript, JPython, etc.

Схоже питання я знайшов тут:
http://slashdot.org/article.pl?sid=00/10/20/2259228&mode=thread
Але після цього вже пройшло багато часу. Думав, що можливо щось змінилося. Та схоже на те, що ні.
В принципі, SWIG - це зараз мабуть найкращий спосіб взаємодії скриптів з бібліотеками на C/C++ в Linux.

Напевно що так. Але коло інтерпретаторів, які підтримуються SWIG-ом, все ще обмежене.

[Юрій Ткаченко]

Можливо з часом Ява (яка чудово компілюється gcc-кою і може бути зінтегрована напевно з будь-якою мовою) стане таким стандартом - тоді будь-яку скомпільовану gcc-кою явовську бібліотеку можна буде викликати напряму з інтерпретаторів приблизно так само як в JavaScript, JPython, etc.

Яким чином? Через JNI? (я ніколи серйозно не працював з Java, тому цікаво)

[Володимир Лісівка]

Яким чином? Через JNI? (я ніколи серйозно не працював з Java, тому цікаво)

Напевно що. Доступ може бути і через Cygnus Native Interface - тобто програми на C++ будуть мати прямий досту, без врапання. Gcj може скомпілювати .jar-ку в .so-ку.

Скриптові оболнки використовуватимуть або JNI або CNI для доступу до якогось двигунця, який використовуватиме reflection для динамічного аналізу наявних бібліотек та класів та передання викликів з скриптової мови у явівські класи та навпаки та врапер для передачі складних об'єктів у обидві сторони (щоб викликана функція могла повертати та приймати не лише прості типи). Це не є складно, таких двигунців вже є багато (кожна скриптова мова на Яві має такий), їх просто треба використати.