Re[3]: COMBridge DEMO
От: SPeller  
Дата: 01.06.09 00:03
Оценка:
A>несколько лет, пока он изучает все плохо документированные особенности DCOM

Как показал опыт — не обязательно тратить несколько лет на это
Re[10]: COMBridge DEMO
От: Figaro Россия  
Дата: 01.06.09 05:02
Оценка:
Если вспомнить классику, то старый любимый POP3... Порты на память не помню, но для KOI8-R и CP1251 они различались.
Хотя это все некритично, но не люблю ограничений Сегодня-завтра гляну, демку скачал...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[22]: COMBridge DEMO
От: araud  
Дата: 01.06.09 10:15
Оценка:
Здравствуйте, SPeller, Вы писали:

A>>я говорю, посмтори статью про интерцепторы тут на rsdn. Там уже все сделано что необходимо для Delphi.

A>>Но вообще конечно мне не понтно желание работать с Delphi когда есть шарп. А в дотнете решена поблема транспортов.

SP>Что-то я не нашел ничего с дельфийскими примерами. Видел только статью про интерсептор в первой части про перехват методов COM интерфейсов, но там всё тот же си. Да и вообще, какая разница на чем писать? У каждого языка есть свои плюсы. У нас задействованы плюсы дельфей. Тем более, что 2009-я стала достаточно вкусной. Кроме того, против дотнета у нас есть свои моменты. Да и свой транспорт можно будет расширить и общаться хоть по почте, добавлять любое шифрование. Я не стал завязываться на TCP и сделал основу расширяемой. Можно пайпы задействовать для общения внутри компа, можно вообще прямые вызовы делать если в одном процессе клиент и сервер. Да, это всё смахивает на то, что уже реализовано в COM, но я делаю упор на то, что приложение не зависит от регистраций компонент в реестре. Запустил — заработало, не ругается что "интерфейс не зарегистрирован". Это во-первых, а во-вторых, у юзера не всегда могут быть права на запись в реестр. И вообще, я противник загаживания реестра


A>>если создаешь объект через ComBridge то все его интерфейсы и все что из него можно получить будет на канале ComBridge с тем компом

A>>откуда получили первый объект

SP>У меня так же ) Можно создавать сколько угодно серверов и клиентских соединений. Где объект создался, там и будет висеть связь с ним.


SP>Еще вопрос — у вас потоковые модели поддерживаются все?

Да, но основное тестирование было на малтитредет.
Re[11]: COMBridge DEMO
От: araud  
Дата: 01.06.09 10:18
Оценка:
Здравствуйте, Figaro, Вы писали:

F>Если вспомнить классику, то старый любимый POP3... Порты на память не помню, но для KOI8-R и CP1251 они различались.

F>Хотя это все некритично, но не люблю ограничений Сегодня-завтра гляну, демку скачал...

Я не понимаю, как локализация связана с портами
Re[12]: COMBridge DEMO
От: Figaro Россия  
Дата: 01.06.09 10:59
Оценка:
Да POP3 отдавал письма в кодировке зависящей от порта... Но это уже ностальгия
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[4]: COMBridge DEMO
От: araud  
Дата: 01.06.09 16:40
Оценка:
Здравствуйте, SPeller, Вы писали:

A>>несколько лет, пока он изучает все плохо документированные особенности DCOM


SP>Как показал опыт — не обязательно тратить несколько лет на это

Я думаю, задача поддержать только ole совместимые интерфейсы действительно не сложна.
А вот ВСЕ случаи DCOM-а это уже посложнее. Одни асинхронные вызовы чего стоят. Да еще добится чтобы эта схема была оптимальна с точки зрения трафика и скорости вызова. Сделать чтобы все это не блокировалось при хаотическом использовании не менее чем 900 интерфесов одновременно. Еще очень много всяких тонкостей, многие из которых не документированы вообще, но если их не реализовать, то будет очень странно глючить.
Re[5]: COMBridge DEMO
От: SPeller  
Дата: 02.06.09 01:37
Оценка:
A>Я думаю, задача поддержать только ole совместимые интерфейсы действительно не сложна.
A>А вот ВСЕ случаи DCOM-а это уже посложнее. Одни асинхронные вызовы чего стоят. Да еще добится чтобы эта схема была оптимальна с точки зрения трафика и скорости вызова. Сделать чтобы все это не блокировалось при хаотическом использовании не менее чем 900 интерфесов одновременно. Еще очень много всяких тонкостей, многие из которых не документированы вообще, но если их не реализовать, то будет очень странно глючить.

У меня небыло цели держать только OLE, хотя использую пока только OLE-совместимые интерфейсы. Но разве есть разница если прокси-стабы я создаю через CreateXXXXFromTypeInfo? Мне совершенно фиолетово что и как передается в параметрах, маршалингом всего этого добра занимается система. Интерфейсы в параметрах я тоже не руками вытаскиваю, а предоставляю эту заботу системе, я только отдаю ей свои данные для записи в пакет, который пойдет на другую сторону. Асинхронные вызовы... На дельфе это сделать так, как делает студия, не получится, поэтому на этом не заостряюсь, но моя система позволяет делать асинхронные запросы серверу без ожидания ответа. Можно сделать, например, чтобы функции, чье имя начинается на Async, вызывались асинхронно. Замаскироваться и действовать как система вряд ли получится, но создавать код, изначально рассчитанный на такую работу — можно. Про асинхронные вызовы читал, суть работы представляю, реализовать можно. Понадобится — можно и broadcast сделать. Вобщем, направления у нас с вами разные, конкурентами если и будем, то не сильно
Re[6]: COMBridge DEMO
От: araud  
Дата: 02.06.09 09:00
Оценка:
Здравствуйте, SPeller, Вы писали:

A>>Я думаю, задача поддержать только ole совместимые интерфейсы действительно не сложна.

A>>А вот ВСЕ случаи DCOM-а это уже посложнее. Одни асинхронные вызовы чего стоят. Да еще добится чтобы эта схема была оптимальна с точки зрения трафика и скорости вызова. Сделать чтобы все это не блокировалось при хаотическом использовании не менее чем 900 интерфесов одновременно. Еще очень много всяких тонкостей, многие из которых не документированы вообще, но если их не реализовать, то будет очень странно глючить.

SP>У меня небыло цели держать только OLE, хотя использую пока только OLE-совместимые интерфейсы. Но разве есть разница если прокси-стабы я создаю через CreateXXXXFromTypeInfo? Мне совершенно фиолетово что и как передается в параметрах, маршалингом всего этого добра занимается система. Интерфейсы в параметрах я тоже не руками вытаскиваю, а предоставляю эту заботу системе, я только отдаю ей свои данные для записи в пакет, который пойдет на другую сторону. Асинхронные вызовы... На дельфе это сделать так, как делает студия, не получится, поэтому на этом не заостряюсь, но моя система позволяет делать асинхронные запросы серверу без ожидания ответа. Можно сделать, например, чтобы функции, чье имя начинается на Async, вызывались асинхронно. Замаскироваться и действовать как система вряд ли получится, но создавать код, изначально рассчитанный на такую работу — можно. Про асинхронные вызовы читал, суть работы представляю, реализовать можно. Понадобится — можно и broadcast сделать. Вобщем, направления у нас с вами разные, конкурентами если и будем, то не сильно


CreateXXXXFromTypeInfo требует наличия TypeInfo
И можно ли пересадить на Ваш транспорт ЛЮБОЙ поект, не изменяя код, кроме кода установки соединения с сервером?
Re[7]: COMBridge DEMO
От: SPeller  
Дата: 03.06.09 00:06
Оценка:
A>CreateXXXXFromTypeInfo требует наличия TypeInfo
A>И можно ли пересадить на Ваш транспорт ЛЮБОЙ поект, не изменяя код, кроме кода установки соединения с сервером?

Чтобы получить TypeInfo нужна Typelib, которая нужна и стандартному DCOM-у, без этого компонента никто не сможет работать, бо иных стандартных средств описания интерфейсов, функций и параметров нет.

На мой транспорт ЛЮБОЙ проект без доработок не пересадишь, потому что мой транспорт ничего не берет из реестра со всеми вытекающими. Мой транспорт заменяет собой DCOM, а не встраивается в существующий, потому и полностью совместимым он быть не может.
Re[8]: COMBridge DEMO
От: araud  
Дата: 03.06.09 11:28
Оценка:
Здравствуйте, SPeller, Вы писали:

A>>CreateXXXXFromTypeInfo требует наличия TypeInfo

A>>И можно ли пересадить на Ваш транспорт ЛЮБОЙ поект, не изменяя код, кроме кода установки соединения с сервером?

SP>Чтобы получить TypeInfo нужна Typelib, которая нужна и стандартному DCOM-у, без этого компонента никто не сможет работать, бо иных стандартных средств описания интерфейсов, функций и параметров нет.


-- да ты чо, либо я чего то незнал, либо ты Библиотека типов не нужна не оле совместимым интерфейсам. Я вырубаю генерацию библиотеки типов во всех своих проектах и нет никаких проблем. Библиотека типов нужна только для динамического связывания.

SP>На мой транспорт ЛЮБОЙ проект без доработок не пересадишь, потому что мой транспорт ничего не берет из реестра со всеми вытекающими. Мой транспорт заменяет собой DCOM, а не встраивается в существующий, потому и полностью совместимым он быть не может.

--Ясно, оттого и сложность нашего проекта, что он ведет себя полностью как DCOM, со всеми тонкостями.
Re[9]: COMBridge DEMO
От: SPeller  
Дата: 04.06.09 01:32
Оценка:
A>-- да ты чо, либо я чего то незнал, либо ты Библиотека типов не нужна не оле совместимым интерфейсам. Я вырубаю генерацию библиотеки типов во всех своих проектах и нет никаких проблем. Библиотека типов нужна только для динамического связывания.

Ты забыл что дельфя не генерит прокси-стабы как это делает студия. У вас прокси-стабы статические, а в дельфе такие стабы либо писать руками, либо генерить динамически на основе библиотеки типов. Ку?
Re[10]: COMBridge DEMO
От: araud  
Дата: 04.06.09 04:47
Оценка:
Здравствуйте, SPeller, Вы писали:

A>>-- да ты чо, либо я чего то незнал, либо ты Библиотека типов не нужна не оле совместимым интерфейсам. Я вырубаю генерацию библиотеки типов во всех своих проектах и нет никаких проблем. Библиотека типов нужна только для динамического связывания.


SP>Ты забыл что дельфя не генерит прокси-стабы как это делает студия. У вас прокси-стабы статические, а в дельфе такие стабы либо писать руками, либо генерить динамически на основе библиотеки типов. Ку?


Действительно забыл . Я на делфе в последний раз что-то делал лет 6 назад
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.