Здравствуйте, Beam, Вы писали:
B>Всем привет.
B>Пусть у нас есть несколько программ/библиотек, написанных на разных языках, под разные платформы. B>Как следствие они не совместимы между собой. Например, Java — wxWidgets, Haskell — Prolog, VB — Smalltalk и т.д. B>Иногда, хочется наладить взаимодействие между ними. Часто для этого пишут мосты.
Старый ответ: CORBA. Можешь заинтеропится хоть с мэйнфреймом, где крутится система на коболе.
Новый ответ: Enterprise Bus Architecture. Конкретнее — рекомендуется пристально взглянуть на AMQP. Можно связать географически распределенные системы, и использовать в качестве транспорта хоть голуюиную почту.
Если речь идет о взаимодействии на одной машине, то это, безусловно, COM под вендой, и, по всей видимости, dbus под Linux.
Здравствуйте, Beam, Вы писали:
B>Хочу совместить несовместимое. Чтобы я, пользователь платформы X, легко мог использовать библиотеку для платформы Y. И здесь важен не только сам XML-RPC, но и то, что передается внутри.
B>Только непонятно, возможно ли? надо ли?
1. Непонятно, для начала, что именно предлагается передавать. Я надеюсь, представления о возможных различиях в системах типов интегрируемых платформ уже есть? Любой протокол интеграции должен что-то предлагать. Даже в голых сокетах есть ntohl, htonl для борьбы с проблемами разного byte order.
Если мы рассматирваем чуть более высокий уровень, то начинаются прямо-таки чудовищные проблемы. И чем выше, тем хуже.
2. Второй момент, который хочется упомянуть, это производительность. Тот же XML-RPC, не к ночи будь помянут, чудовищно избыточен. Меня тут уже критиковали за то, что я привожу плохие примеры, но улучшение примеров быстро приведет к деградации абстракции типов данных. В итоге всё равно окажется, что XML-RPC еще более-менее пригоден для SOA, для склейки небольшого количества сложных систем, которые относительно редко обмениваются сообщениями, но для локальной интеграции библиотек, через границу которых должны проходить сотни тысяч вызовов в секунду, XML-RPC непригоден.
Если отвлечься от XML-RPC, то станет ясно, что проблемы п.2 непосредственно связаны с п.1. У нас есть две разные платформы; вызовы между ними нужно как-то маршалить. Полностью платформенно-независимый протокол потребует больших затрат на маршалинг, что мы и видим в SOAP и XML-RPC. Платформенно-зависимые интеграционные протоколы (PInvoke, JNI) ведут себя гораздо лучше, но всё еще сильно отстают от "родных" библиотек, позволяющих внутриплатформенные вызовы.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Пусть у нас есть несколько программ/библиотек, написанных на разных языках, под разные платформы.
Как следствие они не совместимы между собой. Например, Java — wxWidgets, Haskell — Prolog, VB — Smalltalk и т.д.
Иногда, хочется наладить взаимодействие между ними. Часто для этого пишут мосты.
Один из самых простых способов самому организовать такое взаимодействие — использовать сокеты. Как правило все платформы имеют все необходимое для работы с ними. Остается придумать протокол и вперёд!.
Плохо то, что постоянно изобретают свои протоколы. Например, java-prolog — один протокол, а в другом проекте haskell-prolog — другой.
Какие стандартные протоколы есть для такого взаимодействия? Ведь поддерживая стандарт для каждой из платформ можно было бы наладить взаимодействие с любыми двумя системами.
Например Java могла бы реализовать так: получаем сообшение с названиями методов и параметры, вызываем их.
На Прологе: получаем сообщение с фактами и целями, находим решение. и т.п.
И пожалуйста — обращайся из haskell к prolog или к java, все легко (легко ли?).
XML-RPC вроде хорош. Однако он заточен под вызов процедур, но не все меряется процедурами и функциями. Хотя притянуть за уши можно все. Может это вообще должен быть обычный построчный протокол с передачей данных в JSON?
А может это вовсе не надо никому, вот и не используют? Или есть технические проблемы (скорость и пр.)?
Однако ж мосты, все же пишут...
Здравствуйте, Beam, Вы писали:
B>Всем привет.
... B>Однако ж мосты, все же пишут...
А что тут думать? Выбираете стандартный протокол из имеющих реализацию для всех целевых платформ и вперед. Это может быть как и XML-RPC, SOAP, так и например что-то типа CORBA. Подтянуть любое приложение и сделать из него некий сервис обычно достаточно легко. Надо просто понять чего вы хотите получить от протокола, какие у вас требования по организации инфраструктуры взаимодействия.
Здравствуйте, Beam, Вы писали:
B>Всем привет.
B>Пусть у нас есть несколько программ/библиотек, написанных на разных языках, под разные платформы. B>Как следствие они не совместимы между собой. Например, Java — wxWidgets, Haskell — Prolog, VB — Smalltalk и т.д. B>Иногда, хочется наладить взаимодействие между ними. Часто для этого пишут мосты.
Рассматривается ли локальный вызов? Если да, то чем FFI (к примеру для haskell) не подходит?
Здравствуйте, Daevaorn, Вы писали:
D>А что тут думать? Выбираете стандартный протокол из имеющих реализацию для всех целевых платформ и вперед. Это может быть как и XML-RPC, SOAP, так и например что-то типа CORBA.
Согласен, что если уже реализован XML-RPC, то это хороший вариант. А если нет? XML-RPC вроде идет через HTTP, т.е. как минимум должен быть реализован HTTP сервер. Но может я преувеличиваю, все-таки XML-RPC доступен для большинства языков/платформ.
SOAP и CORBA достаточно сложны.
D>Подтянуть любое приложение и сделать из него некий сервис обычно достаточно легко. Надо просто понять чего вы хотите получить от протокола, какие у вас требования по организации инфраструктуры взаимодействия.
Хочу совместить несовместимое. Чтобы я, пользователь платформы X, легко мог использовать библиотеку для платформы Y. И здесь важен не только сам XML-RPC, но и то, что передается внутри.
1. Допустим кто-то сделал библиотеку на Java. Ее могут использовать пользователи Java.
2. Реализуем XML-RPC для вызова библиотеки. Это предлагается сделать.
3. Однако, если уже реализован вызов ЛЮБЫХ методов Java через XML-RPC, то эта библиотека уже доступна всем (объем труда для организации взаимодействия — 0).
4. Если реализовать специальный DSL через XML-RPC, то эта библиотека доступна всем и ОЧЕНЬ ЛЕГКА В ИСПОЛЬЗОВАНИИ. (объем труда для создателя библиотеки не должен быть большим).
Вместо Java подставьте платформу/систему/библиотеку
п.1 — делают все
п.2 — делают когда надо
п.3 — почти никогда не делают
п.4 — еще реже, чем п.3
Я говорю о п.3. Если есть п.3, то не нужен п.2
Только непонятно, возможно ли? надо ли?
И речь не идет о конкретном решении, это ж философия
Здравствуйте, Beam, Вы писали:
B>Здравствуйте, Курилка, Вы писали:
К>>Рассматривается ли локальный вызов? Если да, то чем FFI (к примеру для haskell) не подходит?
B>FFI — это только для Haskell. Я говорю про более универсальные вещи — как соединить Haskell со всем, чем можно.
Я ведь написал к примеру...
Почитай вики хотябы (если букв много, то глянь список языков в разделе Examples)
Здравствуйте, Beam, Вы писали:
B>1. Допустим кто-то сделал библиотеку на Java. Ее могут использовать пользователи Java. B>2. Реализуем XML-RPC для вызова библиотеки. Это предлагается сделать. B>3. Однако, если уже реализован вызов ЛЮБЫХ методов Java через XML-RPC, то эта библиотека уже доступна всем (объем труда для организации взаимодействия — 0). B>4. Если реализовать специальный DSL через XML-RPC, то эта библиотека доступна всем и ОЧЕНЬ ЛЕГКА В ИСПОЛЬЗОВАНИИ. (объем труда для создателя библиотеки не должен быть большим).
Только если ты берёшь RPC, то у тебя должен быть постоянно запущен некий host-процесс, аля Java RMI, только зачем такие накладные расходы, тем более что ты хочешь вызывать большое число разных библиотек, так что расходы будут ещё и на определение "платформы/языка", инструментацию кода...
Только вот какой смысл, если можно взять и использовать какой-нибудь SWIG?
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, Beam, Вы писали:
B>>Здравствуйте, Курилка, Вы писали:
К>>>Рассматривается ли локальный вызов? Если да, то чем FFI (к примеру для haskell) не подходит?
B>>FFI — это только для Haskell. Я говорю про более универсальные вещи — как соединить Haskell со всем, чем можно.
К>Я ведь написал к примеру... К>Почитай вики хотябы (если букв много, то глянь список языков в разделе Examples)
Нда... Че-то переклинило меня, что FFI — это название интерфейса к С для Haskell.
Wiki почитал. То что букв много, это даже хорошо, лишь бы в тему.
Возвращаясь к вопросу о FFI.
Из плюсов — скорость, из минусов — привязка к нативному коду.
Ну и сами вызовы:
В XML-RPC нарисовал сервер (Haskell, Python) и любые клиенты (Java, VB, Prolog) этот сервер могут использовать.
В FFI я такое плохо себе представляю. Там понадобится какой-то промежуточный уровень (dll?), без которого кучу мостов и получаем: Java-Haskell, VB-Haskell, Prolog-Haskell, Java-Python, VB-Python, Prolog-Python. А вот генерировать этот промежуточный уровень не все умеют.
Здравствуйте, Курилка, Вы писали:
К>Только если ты берёшь RPC, то у тебя должен быть постоянно запущен некий host-процесс, аля Java RMI, только зачем такие накладные расходы,
В случае удаленных вызовов не деться от этого. А при локальных зачем постоянно? Надо — запустил. Не надо — отпустил.
К>тем более что ты хочешь вызывать большое число разных библиотек, так что расходы будут ещё и на определение "платформы/языка", инструментацию кода...
Не совсем понятно про определение палтформы/языка. Ну, естественно, расходы выше, чем у нативных вызовов — за гибкость надо платить.
Но лучше иметь медленный вызов, чем не иметь никакого. А при дальнейшем развитии, прямые мосты все равно будут написаны (в случае локальных вызовов), вопрос времени.
Здравствуйте, Beam, Вы писали:
B>Плохо то, что постоянно изобретают свои протоколы. Например, java-prolog — один протокол, а в другом проекте haskell-prolog — другой.
(1) Реализация собственных протоколов не самая сложная и ресурсоемкая часть работы
(2) Чем более общая реализация, тем больше заточка нужна в частном конкретном случае
По второму пункту, например, часто кроме универсального решения строят еще парочку мостов, чтобы соединить этот универсальный протокол с конкретной реализацией.
Ну и у каждого случая своя специфика. Если это игровой сервер, то нам важна скорость обработки сообщений (выстрел из БФГ оборачивается XML-иной, шлется на сервер, там парсится...) Если это SQL сервер, то важно передавать большие объемы.
Механизмы взаимодействия есть (тот же RPC). Часто в платформе инструменты для такого взаимодействия реализованы.
Непонятно, почему сразу не реализовать доступ к функционалу платформы/системы, через эти интерфейсы?
Гипотетический пример — Пролог. Поддержка XML-RPC есть, но нет готового модуля для передачи целей и фактов через него.
Почему до сих пор не существует общего знаменателя для нативного кода различных систем?
Что-то типа платформо-независимых obj-файлов для С, из которых будет сформирован нативный код.
Большое количество алгоритмов могло быть записано именно в таком виде (сортировка, поиск, контейнеры и многое, многое другое)
Да есть С/С++. Написано однажды, работает везде. Но это нужно очень постараться (я так думаю, хотя на С и С++ не пишу).
И есть виртуальные машины (JVM, CLR, ...), которые тянут одеяло на себя, которые не заменяют С/С++, достаточно далеко уходя от аппаратной платформы, которые добавляют кучу специфичного своего, и в которых большая часть библиотек/алгоритмов пересекается.
Здравствуйте, Sinclair, Вы писали:
S>1. Непонятно, для начала, что именно предлагается передавать. Я надеюсь, представления о возможных различиях в системах типов интегрируемых платформ уже есть? Любой протокол интеграции должен что-то предлагать. Даже в голых сокетах есть ntohl, htonl для борьбы с проблемами разного byte order.
Передавать обычные текстовые сообщения (XML-RPC или даже обычные строки), понятные принимающей платформе (в терминах ее предметной области). Как SQL.
S>Если мы рассматирваем чуть более высокий уровень, то начинаются прямо-таки чудовищные проблемы. И чем выше, тем хуже.
Что за проблемы? Трудность (или даже невозможность) преобразования типов? Или что-то иное?
S>2. Второй момент, который хочется упомянуть, это производительность. Тот же XML-RPC, не к ночи будь помянут, чудовищно избыточен. Меня тут уже критиковали за то, что я привожу плохие примеры, но улучшение примеров быстро приведет к деградации абстракции типов данных. В итоге всё равно окажется, что XML-RPC еще более-менее пригоден для SOA, для склейки небольшого количества сложных систем, которые относительно редко обмениваются сообщениями, но для локальной интеграции библиотек, через границу которых должны проходить сотни тысяч вызовов в секунду, XML-RPC непригоден.
Согласен, что для такого количества вызовов в секунду любой текстовый протокол, да и, скорее всего, вообще взаимодействие через сокет не подойдет. Но увеличивая мощность языка для доступа к принимаюшей платформы (количество действий на одно принятое сообщение) можно значительно снизить overhead.
S>Если отвлечься от XML-RPC, то станет ясно, что проблемы п.2 непосредственно связаны с п.1. У нас есть две разные платформы; вызовы между ними нужно как-то маршалить. Полностью платформенно-независимый протокол потребует больших затрат на маршалинг, что мы и видим в SOAP и XML-RPC.
Самый простой платформо-независимый протокол — обычные текстовые строки, ну или структуры наподобие JSON. И для передачи некого DSL (типа SQL) он неплохо подходит. И его можно очень легко реализовать.
S>Платформенно-зависимые интеграционные протоколы (PInvoke, JNI) ведут себя гораздо лучше, но всё еще сильно отстают от "родных" библиотек, позволяющих внутриплатформенные вызовы.
Для быстрых локальных вызовов, остается нативный код, и я уже писал о том, что было бы хорошо иметь некий платфомо-независимый промежуточный уровень для взаимодействия. Причем не физический уровень, который бы на этапе линковки/запуска полностью бы устранялся.
P.S. В общем я призываю для библиотек/систем писать DSL.
Здравствуйте, Beam, Вы писали:
B>Передавать обычные текстовые сообщения (XML-RPC или даже обычные строки), понятные принимающей платформе (в терминах ее предметной области). Как SQL. S>>Если мы рассматирваем чуть более высокий уровень, то начинаются прямо-таки чудовищные проблемы. И чем выше, тем хуже. B>Что за проблемы? Трудность (или даже невозможность) преобразования типов? Или что-то иное?
Трудность найти правильное соответствие целевому типу. Вот, к примеру, у нас библиотека работает с float. Что будем ставить в соответствие на вызывающей стороне? 32бит? 64? 80?
Это еще цветочки. А вот, к примеру, ягодки — это передача значений типа ДатаВремя. Это ж зоопарк — у кого в них календарь встроен, у кого нет. Где-то есть встроенный часовой пояс, а кто-то ожидает UTC. Кто-то включает в UTC daylight savings, а кто-то нет.
B>Согласен, что для такого количества вызовов в секунду любой текстовый протокол, да и, скорее всего, вообще взаимодействие через сокет не подойдет.
Ничего подобного. Сам сокет — супербыстрая штука, для loopback его производительность просто огромна. Это я еще не говорю о том, что за протоколом, выглядящим как сокет, может скрываться какой-нибудь shared memory, и перекачка данных через него будет заведомо превышать скорость парсинга строк.
B>Но увеличивая мощность языка для доступа к принимаюшей платформы (количество действий на одно принятое сообщение) можно значительно снизить overhead.
Это утверждение не понял.
B>Самый простой платформо-независимый протокол — обычные текстовые строки, ну или структуры наподобие JSON. И для передачи некого DSL (типа SQL) он неплохо подходит. И его можно очень легко реализовать.
Это заблуждение, которое быстро проходит с оптыом. Я имею в виду про "самый простой". Для начала рекомендую ознакомиться с существующими стандартами кодирования комплексных данных в "простые строки". Например, в том же XML (не говоря о SOAP).
И про "легко реализовать" — тоже ничего похожего. Если сделать протокол слишком примитивным, например не вводить стандарт на тип для даты и времени, то реализации будут испытывать искушение задавать свои кодировки. Кто-то захочет таймстэмп передавать как сериализованную строку для флоата в OLE формате, кто-то как RFC 822. В итоге "обвязки" к каждой системе превысят объем "стандартного" кода, а это фактически означает бесполезность стандарта.
B>Для быстрых локальных вызовов, остается нативный код, и я уже писал о том, что было бы хорошо иметь некий платфомо-независимый промежуточный уровень для взаимодействия. Причем не физический уровень, который бы на этапе линковки/запуска полностью бы устранялся.
Вот этот момент непонятен вообще никак. Куда ты собираешься устранять на этапе запуска код, который сериализует данные из одного формата, и десериализует в другой?
Даже если с обоих концов — совершенно одинаковые платформы, никакой линкер неспособен устранить среднее звено в socket << myObject; socket >> myObject. B>P.S. В общем я призываю для библиотек/систем писать DSL.
Во-первых, непонятно, почему библиотеки и системы пишутся через слэш. Задачи интеграции для них имеют совершенно различную природу. Во-вторых, пока что непонятно, что такое этот DSL. До сих пор в топике звучали только абсолютно противоположные призывы — написать General Purpose Language, а никакой не Domain-Specific.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Beam, Вы писали:
B>>Передавать обычные текстовые сообщения (XML-RPC или даже обычные строки), понятные принимающей платформе (в терминах ее предметной области). Как SQL. S>
Здесь по-подробнее, пожалуйста. Что улыбнуло?
S>Трудность найти правильное соответствие целевому типу. Вот, к примеру, у нас библиотека работает с float. Что будем ставить в соответствие на вызывающей стороне? 32бит? 64? 80?
Протокол текстовый. Значит должно быть передано текстовое значение float. Про скорость говорить пока не будем.
S>Это еще цветочки. А вот, к примеру, ягодки — это передача значений типа ДатаВремя. Это ж зоопарк — у кого в них календарь встроен, у кого нет. Где-то есть встроенный часовой пояс, а кто-то ожидает UTC. Кто-то включает в UTC daylight savings, а кто-то нет.
Ожидает UTC — даем UTC. К непосредственному обмену данных это не имеет никакого отношения.
Чтобы избежать зоопарка, нужны дополнительные стандарты, но не на низком уровне передачи данных.
Например, есть некая система. Она заявляет, что поддерживает формат обмена X (обмен текстовыми строками). Теперь мы можем отправлять ей сообщения. Для отправки ей времени должны понять, в каком виде она его хочет. Узнали — отправили.
Проблема — вызывающая сторона должна подстраиваться под все системы, с которыми она работает.
Для устранения проблемы, вызываемая система заявляет поддержка Y, из чего следует, что дата и время передается в UTC, а float с точность n знаков. В вызывающей системе есть поддержка для работы с Y, все упрощается.
Т.е. X — механизм передачи данных. Y — формат элементов данных, и т.д.
S>Ничего подобного. Сам сокет — супербыстрая штука, для loopback его производительность просто огромна. Это я еще не говорю о том, что за протоколом, выглядящим как сокет, может скрываться какой-нибудь shared memory, и перекачка данных через него будет заведомо превышать скорость парсинга строк.
Где-то есть информация о производительности сокетов? Искал, не нашел.
B>>Но увеличивая мощность языка для доступа к принимаюшей платформы (количество действий на одно принятое сообщение) можно значительно снизить overhead. S>Это утверждение не понял.
Принимающая система обрабатывает сообщение 0,1 сек. Если парсинг сообщения занимает 0,01 сек, overhead 10%
Если система получает более крупные задания, для выполнения которых нужно 1 сек, то overhead 1%
B>>Самый простой платформо-независимый протокол — обычные текстовые строки, ну или структуры наподобие JSON. И для передачи некого DSL (типа SQL) он неплохо подходит. И его можно очень легко реализовать. S>Это заблуждение, которое быстро проходит с оптыом. Я имею в виду про "самый простой". Для начала рекомендую ознакомиться с существующими стандартами кодирования комплексных данных в "простые строки". Например, в том же XML (не говоря о SOAP).
В чем заблуждение? Ну тот же JSON чем сложен?
Покритикуйте простой протокол:
В каждом сообщении передается список объектов. Список объектов заключается в квадратные скобки, и разделяется запятыми. Каждый объект в списке может быть либо значением, заключенным в кавычки, либо списком. Разделителями являются пробелы. Кавычки в строке заменяются на двойные.
[ "call", "myfun", ["param1", "param2"] ]
Правда необходимо кодировку подсунуть.
B>>Для быстрых локальных вызовов, остается нативный код, и я уже писал о том, что было бы хорошо иметь некий платфомо-независимый промежуточный уровень для взаимодействия. Причем не физический уровень, который бы на этапе линковки/запуска полностью бы устранялся. S>Вот этот момент непонятен вообще никак. Куда ты собираешься устранять на этапе запуска код, который сериализует данные из одного формата, и десериализует в другой?
Я имею ввиду некий байт-код, приближенный к аппаратной платформе (с регистрами, портами ввода вывода и пр.), который компилируется на конкретной платформе. Байт-код остается не нужным.
Зачем сериализовать? Здесь же идут нативные вызовы. Ведь используя, например, DLL ты же не сериализуешь данные. А это что-то типа платформо-независимых DLL, но в то же время, имеющих плюсы нативных.
B>>P.S. В общем я призываю для библиотек/систем писать DSL.
S>Во-первых, непонятно, почему библиотеки и системы пишутся через слэш. Задачи интеграции для них имеют совершенно различную природу. Во-вторых, пока что непонятно, что такое этот DSL. До сих пор в топике звучали только абсолютно противоположные призывы — написать General Purpose Language, а никакой не Domain-Specific.
DSL для SQL: SELECT ...
DSL для Пролог: rule1, rule2, goal ...
DSL для wxWidgets: Windows at posX posY [Button "Super Button"]
Здравствуйте, Beam, Вы писали: B>Здесь по-подробнее, пожалуйста. Что улыбнуло?
Улыбнула трактовка SQL как "текстовых строк". Рекомендую на досуге ознакомиться с каким-нибудь открытым протоколом RBDMS. Например, TDS.
B>Протокол текстовый. Значит должно быть передано текстовое значение float. Про скорость говорить пока не будем.
Ок, давайте поговорит про "текстовое значение". Как именно оно будет кодироваться? Ну вот хотя бы разделитель целой и дробной частей будет каким? Сколько знаков в мантиссе обязана поддерживать реализация протокола? Какие ограничения на экспоненту?
B>Ожидает UTC — даем UTC.
Кто ожидает-то? Речь идет о том, что, к примеру, на вызываемой стороне требуется FILETIME, а на вызывающей есть только DateTime. Кто будет заниматься маршалингом? B>К непосредственному обмену данных это не имеет никакого отношения.
Имеет, и еще какое. B>Чтобы избежать зоопарка, нужны дополнительные стандарты, но не на низком уровне передачи данных.
"Низкий" уровень передачи данных есть уже давно. Чем ваш подход лучше, чем к примеру обмен байтами?
B>Например, есть некая система. Она заявляет, что поддерживает формат обмена X (обмен текстовыми строками). Теперь мы можем отправлять ей сообщения. Для отправки ей времени должны понять, в каком виде она его хочет. Узнали — отправили. B>Проблема — вызывающая сторона должна подстраиваться под все системы, с которыми она работает. B>Для устранения проблемы, вызываемая система заявляет поддержка Y, из чего следует, что дата и время передается в UTC, а float с точность n знаков. В вызывающей системе есть поддержка для работы с Y, все упрощается. B>Т.е. X — механизм передачи данных. Y — формат элементов данных, и т.д.
Вы что хотите стандартизовать, X или Y?
B>Где-то есть информация о производительности сокетов? Искал, не нашел.
Где-то — есть.
B>Принимающая система обрабатывает сообщение 0,1 сек. Если парсинг сообщения занимает 0,01 сек, overhead 10% B>Если система получает более крупные задания, для выполнения которых нужно 1 сек, то overhead 1%
И какое отношение это имеет к "мощности языка"? Вот есть, например, абсолютно убогий язык "передача сигнала уровнем напряжения". Там всё просто: есть +24 — значит сигнал сработал. Принимающая сторона знает, что это — сигнал от датчика затопления тоннеля, по срабатыванию которого нужно применить пункт 24.13 инструкции. Выполнение этого пункта занимает 8 часов (если не считать подпункт ш) — "эвакуация гражданского населения из зоны катастрофы"). Оверхед, как видим, практически нулевой.
Стало быть, речь идет не о выразительности языка, а о том, как система декомпозирована на подсистемы. Я уже об этом писал, но вы не стали читать.
B>>>Самый простой платформо-независимый протокол — обычные текстовые строки, ну или структуры наподобие JSON. И для передачи некого DSL (типа SQL) он неплохо подходит. И его можно очень легко реализовать. S>>Это заблуждение, которое быстро проходит с оптыом. Я имею в виду про "самый простой". Для начала рекомендую ознакомиться с существующими стандартами кодирования комплексных данных в "простые строки". Например, в том же XML (не говоря о SOAP).
B>В чем заблуждение?
Я же написал. Читайте мои постинги.
B>Покритикуйте простой протокол: B>В каждом сообщении передается список объектов. Список объектов заключается в квадратные скобки, и разделяется запятыми. Каждый объект в списке может быть либо значением, заключенным в кавычки, либо списком. Разделителями являются пробелы. Кавычки в строке заменяются на двойные. B>[ "call", "myfun", ["param1", "param2"] ] B>Правда необходимо кодировку подсунуть.
1. Что значит "подсунуть"? Где передается информация о кодировке?
2. Во что должна отображаться эта информация на принимающей стороне? Предположим, речь идет о языке С.
3. Что именно отдает передающая сторона в библиотеку, реализующую данный протокол? Предположим, речь идет о Фортране.
B>Я имею ввиду некий байт-код, приближенный к аппаратной платформе (с регистрами, портами ввода вывода и пр.), который компилируется на конкретной платформе. Байт-код остается не нужным.
Всё еще непонятно. Что такое "байт-код"? Мы пока что говорим об интеграции двух платформ. Например, одна на С, другая на хаскеле. Откуда тут взялся байт-код? B>Зачем сериализовать? Здесь же идут нативные вызовы.
Никаких нативных вызовов я не вижу. Я вижу только какой-то недоспецифицированный протокол для передачи структур строковых данных. Для того, чтобы отправить банальный инт32, мне нужно сконвертировать его в строку, заключить в кавычки и квадратные скобки. Принимающая сторона
B>Ведь используя, например, DLL ты же не сериализуешь данные.
Правильно, потому что DLL оставляет за кадром вопрос согласования calling convention. Ты вот, к примеру, про маршаллинг managed/unmanaged что-нибудь слышал? А ведь это чистый "вызов DLL".
B>А это что-то типа платформо-независимых DLL, но в то же время, имеющих плюсы нативных.
B>DSL для SQL: SELECT ... B>DSL для Пролог: rule1, rule2, goal ... B>DSL для wxWidgets: Windows at posX posY [Button "Super Button"]
И? Для всего этого уже есть DSL. Для SQL есть TDS, для windows — Win32 API и Dialog Templates, для пролога — еще что-то. Что предлагается взамен?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Есть задача. Ее можно реализовать на Java. Было бы здорово часть ее реализовать на Prolog (подсистема B), а остальное на Java (A).
Щас мы так и сделаем. Ой. Моста Java-Prolog нет.
Варианты развития событий:
1. Да ну нафиг этот Пролог, напишем все на Java.
2. А нет, есть!!! Java-C, Prolog-C. Давайте напишем на С переходник.
3. А они же поддерживают сокеты, XML-RPC! Давайте напишем сервер на Prolog (хорошо если есть HTTP) и поднимем хост!!.
И еще вариант.
4. Давайте будем передавать сообщений в текстовом виде через сокет, парсить их и выполнять. Для этого у нас есть и в Java и в Prolog сокеты, а также модуль X (sendString и recvString).
Какие сообщения можем посылать? Да только те, которые реализованы в В. В каком формате? Да только в том, который реализован в В. Это и будет DSL для системы В.
п.4 ~= п.3, но проще в реализации. Может и не проще. Это я и хочу узнать. (это вопрос № 1).
Еще вариант.
5. В котором п.4 поддерживается не подсистемой В, а вообще Prolog. Т.е. нам не нужно что-то парсить в системе В. Мы отправляем сообщения в Prolog: "подключи модули системы В, выполни цель"
Какие сообщения можем посылать? Да только те, которые может принять Prolog. То же про формат.
Зачем это нужно? Используя sendString и recvString можно получить доступ к функционалу системы Prolog.
Из любой системы, поддерживающей эти две функции.
Я здесь не сказал ничего нового. Все уже придумано. Но в основном делаются мосты через нативный интерфейс.
Понятно, что производительность на высоте, но и трудоемкость создания (да и использования) таких мостов высокая.
Почему не используются текстовый формат обмена? Т.е. почему скорее будет написан нативный мост, чем текстовый, или, скорее всего, он вообще написан не будет. (это вопрос № 2).
Ну и продолжение беседы...
S>Улыбнула трактовка SQL как "текстовых строк". Рекомендую на досуге ознакомиться с каким-нибудь открытым протоколом RBDMS. Например, TDS.
Про SQL я говорил как о представления команды, а не как о способе передаче.
S>Ок, давайте поговорит про "текстовое значение". Как именно оно будет кодироваться? Ну вот хотя бы разделитель целой и дробной частей будет каким? Сколько знаков в мантиссе обязана поддерживать реализация протокола? Какие ограничения на экспоненту?
см. выше
S>Кто ожидает-то? Речь идет о том, что, к примеру, на вызываемой стороне требуется FILETIME, а на вызывающей есть только DateTime. Кто будет заниматься маршалингом?
см. выше
B>>Чтобы избежать зоопарка, нужны дополнительные стандарты, но не на низком уровне передачи данных. S>"Низкий" уровень передачи данных есть уже давно. Чем ваш подход лучше, чем к примеру обмен байтами?
Под низким уровнем понимается sendString recvString.
Лучше платформо-независимостью.
И это не какой-то новый подход.
B>>Т.е. X — механизм передачи данных. Y — формат элементов данных, и т.д. S>Вы что хотите стандартизовать, X или Y?
X. Чтобы было легче, чем XML-RPC.
S>И какое отношение это имеет к "мощности языка"? Вот есть, например, абсолютно убогий язык "передача сигнала уровнем напряжения". Там всё просто: есть +24 — значит сигнал сработал. Принимающая сторона знает, что это — сигнал от датчика затопления тоннеля, по срабатыванию которого нужно применить пункт 24.13 инструкции. Выполнение этого пункта занимает 8 часов (если не считать подпункт ш) — "эвакуация гражданского населения из зоны катастрофы"). Оверхед, как видим, практически нулевой.
Согласен, термин я выбрал неправильный. Сути этого не меняет — чем больше время выполнения запроса, тем меньше оверхед. Передавая "более сложные запросы" можно уменьшить оверхед.
S>Стало быть, речь идет не о выразительности языка, а о том, как система декомпозирована на подсистемы. Я уже об этом писал, но вы не стали читать.
Согласен, не о выразительности (ну вернее, не всегда о ней). А вот про декомпозицию теперь я не понял.
B>>[ "call", "myfun", ["param1", "param2"] ] B>>Правда необходимо кодировку подсунуть. S>1. Что значит "подсунуть"? Где передается информация о кодировке?
Я знал, что это повод докопаться. ОК. Название кодировки (в соответствии со стандартом ...) передается в самом начале сообщения в кавычках.
S>2. Во что должна отображаться эта информация на принимающей стороне? Предположим, речь идет о языке С. S>3. Что именно отдает передающая сторона в библиотеку, реализующую данный протокол? Предположим, речь идет о Фортране.
Оба ответа — строка.
Вообще, протокол есть смысл обсуждать, только если не устраивают имеющиеся. А этот вопрос не решен.
S>Никаких нативных вызовов я не вижу. Я вижу только какой-то недоспецифицированный протокол для передачи структур строковых данных. Для того, чтобы отправить банальный инт32, мне нужно сконвертировать его в строку, заключить в кавычки и квадратные скобки.
Стоп. Давайте разделим взаимодействие через сокет и через "байт-код"
Все вышесказанное относится к взаимодействию через сокет
B>>Ведь используя, например, DLL ты же не сериализуешь данные. S>Правильно, потому что DLL оставляет за кадром вопрос согласования calling convention. Ты вот, к примеру, про маршаллинг managed/unmanaged что-нибудь слышал? А ведь это чистый "вызов DLL".
"Байт-код" — это про локальные вызовы. В данном контексте байт-код — платформо-независимая библиотека, скомпилированная таким образом в нативный код, чтобы удовлетворять определенному интерфейсу этой нативной платформы (например DLL). (Во я загнул
В рамках взаимодействия — плюс в том, что не надо писать нативные мосты для разных платформ, достаточно для одной.
Я так думаю.
B>>А это что-то типа платформо-независимых DLL, но в то же время, имеющих плюсы нативных. S>
Ну вот опять
S>И? Для всего этого уже есть DSL. Для SQL есть TDS, для windows — Win32 API и Dialog Templates, для пролога — еще что-то. Что предлагается взамен?
Ну вот, плавно перешли на native
Куда ж делись сокеты?
Best regards, Буравчик
Re: Сравнение скорости HTTP, SOAP, RMI, RAW sockets
Нашел интересную статейку, в которой замеряется скорость обмена данным через loopback по протоколам RMI, HTTP, SOAP и RAW Sockets. Soap-Stone: How Fast Is Your Network Today?
B>Я здесь не сказал ничего нового. Все уже придумано. Но в основном делаются мосты через нативный интерфейс. B>Понятно, что производительность на высоте, но и трудоемкость создания (да и использования) таких мостов высокая.
Откуда взялся тезис про высокую трудоемкость создания мостов?
B>Почему не используются текстовый формат обмена? Т.е. почему скорее будет написан нативный мост, чем текстовый, или, скорее всего, он вообще написан не будет. (это вопрос № 2).
Потому, что у этого подхода нет преимуществ.
S>>Ок, давайте поговорит про "текстовое значение". Как именно оно будет кодироваться? Ну вот хотя бы разделитель целой и дробной частей будет каким? Сколько знаков в мантиссе обязана поддерживать реализация протокола? Какие ограничения на экспоненту? B>см. выше
Что смотреть? Если нет ответа на такие простые вопросы, то рассуждать о каком-либо стандарте преждевременно.
S>>Кто ожидает-то? Речь идет о том, что, к примеру, на вызываемой стороне требуется FILETIME, а на вызывающей есть только DateTime. Кто будет заниматься маршалингом? B>см. выше
Что смотреть? Если нет ответа на такие простые вопросы, то рассуждать о каком-либо стандарте преждевременно.
B>>>Чтобы избежать зоопарка, нужны дополнительные стандарты, но не на низком уровне передачи данных. S>>"Низкий" уровень передачи данных есть уже давно. Чем ваш подход лучше, чем к примеру обмен байтами? B>Под низким уровнем понимается sendString recvString. B>Лучше платформо-независимостью.
Очень странно. Какая платформенная зависимость есть в байтах? S>>Вы что хотите стандартизовать, X или Y? B>X. Чтобы было легче, чем XML-RPC.
Ок, давайте стандартизуем транспорт. Чем не устраивают берклеевские сокеты?
B>Я знал, что это повод докопаться. ОК. Название кодировки (в соответствии со стандартом ...) передается в самом начале сообщения в кавычках.
Отлично. В какой кодировке передается название кодировки? В соответствии с каким стандартом будем передавать название кодировки? Домашнее задание: выяснить номер кодовой страницы для Koi-8r.
S>>2. Во что должна отображаться эта информация на принимающей стороне? Предположим, речь идет о языке С. S>>3. Что именно отдает передающая сторона в библиотеку, реализующую данный протокол? Предположим, речь идет о Фортране. B>Оба ответа — строка. Какая именно строка? Юноша, вы вообше сколько представлений знаете для строк? Вам известно, что в Фортране есть два стандарта на представление строк? Что в Delphi есть три типа строк, не считая Wide-Char? Термин BSTR что-нибудь говорит? А Хаскелевские строки как устроены — вам известно?
Ну так с чего вы взяли, что "строка" проще, чем байты?
Ок, отвлечемся от представления строк. Поднимем такой банальный вопрос, как управление памятью. Кто выделяет память для строки, которая передается? Кто ее освобождает и когда?
На приемной стороне, очевидно, это будет другая строка — как я уже написал, строки платформенно зависимы. Кто отвечает за управление памятью для этих строк? Библиотека или вызываемая программа? B>Вообще, протокол есть смысл обсуждать, только если не устраивают имеющиеся. А этот вопрос не решен.
Ну, раз он не решен, наверное стоит засесть за литературу и порешать его. В мире существует бесконечное множество гитик, которые можно было бы изобрести. Вопрос "зачем" мы всегда задаем авторам. А не так, что "от я придумал идею, а вы мне расскажите для чего она нужна".
S>>Никаких нативных вызовов я не вижу. Я вижу только какой-то недоспецифицированный протокол для передачи структур строковых данных. Для того, чтобы отправить банальный инт32, мне нужно сконвертировать его в строку, заключить в кавычки и квадратные скобки.
B>Стоп. Давайте разделим взаимодействие через сокет и через "байт-код" B>Все вышесказанное относится к взаимодействию через сокет
Давайте. Откуда взялся байт-код?
B>>>Ведь используя, например, DLL ты же не сериализуешь данные.
B>"Байт-код" — это про локальные вызовы. В данном контексте байт-код — платформо-независимая библиотека, скомпилированная таким образом в нативный код, чтобы удовлетворять определенному интерфейсу этой нативной платформы (например DLL). (Во я загнул
Ничего не понятно.
B>В рамках взаимодействия — плюс в том, что не надо писать нативные мосты для разных платформ, достаточно для одной. B>Я так думаю.
B>>>А это что-то типа платформо-независимых DLL, но в то же время, имеющих плюсы нативных. S>> B>Ну вот опять
S>>И? Для всего этого уже есть DSL. Для SQL есть TDS, для windows — Win32 API и Dialog Templates, для пролога — еще что-то. Что предлагается взамен? B>Ну вот, плавно перешли на native B>Куда ж делись сокеты?
Сокеты умерли для случаев высокопроизводительного обмена.
А в чем проблема, которую хочется решить? Я всё еще не понимаю, что будет делать предлагаемая платформа. send и recv уже есть. Дальше что?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Откуда взялся тезис про высокую трудоемкость создания мостов? B>>Почему не используются текстовый формат обмена? Т.е. почему скорее будет написан нативный мост, чем текстовый, или, скорее всего, он вообще написан не будет. (это вопрос № 2). S>Потому, что у этого подхода нет преимуществ.
Я действительно исходил из того, что мост написать нелегко. Хотя бы потому, что необходимо знать внутреннее устройство обоих систем.
В принципе, Вы ответили на мои вопросы, которые звучали. Как я понял, это не нужно, т.к. если понадобится взаимодействие (локальное), написать мост не составит большого труда, к тому же он более эффективен.
S>Ок, давайте стандартизуем транспорт. Чем не устраивают берклеевские сокеты?
Только тем, что не вводят никакого логического деления информации.
S> Какая именно строка? Юноша, вы вообше сколько представлений знаете для строк? Вам известно, что в Фортране есть два стандарта на представление строк? Что в Delphi есть три типа строк, не считая Wide-Char? Термин BSTR что-нибудь говорит? А Хаскелевские строки как устроены — вам известно? S>Ну так с чего вы взяли, что "строка" проще, чем байты?
Про фортран не знаю. Про delphi, haskell известно. Это не мешает их строки преобразовать к виду "...." (в определенной кодировке) и пустить в поток.
Строка — как платформо-независимое средство выделения логических блоков информации в потоке. Вон тот же HTTP, SMTP.
Предложите другое. И чем "байты" у Вас отличаются от "строки".
S>Откуда взялся байт-код?
Это о том, как просто было бы налаживать локальное быстрое нативное взаимодействие, если бы все системы были скомпилированы в некий байт-код, который, в свою очередь, компилировался бы в нативную платформу. Мысли не более. К сокетам и текстовому обмену отношения не имеет.
S>Сокеты умерли для случаев высокопроизводительного обмена.
Ваша точка зрения ясна.
S>А в чем проблема, которую хочется решить? Я всё еще не понимаю, что будет делать предлагаемая платформа. send и recv уже есть. Дальше что?
Я не предлагаю никакую платформу.
Это рассуждение на тему: было бы здорово иметь доступ через сокет к функционалу ЛЮБОЙ системы. Не прилагая усилий со стороны клиента по написанию мостов.
Т.е. чтобы разработчик системы, сразу сделал бы к ней "текстовый интерфейс". Вот и интересовал вопрос: почему разработчик не сделал, как он это мог бы сделать (протоколы), насколько просто взаимодействовать через такой интерфейс.
Здравствуйте, Beam, Вы писали:
B>Я действительно исходил из того, что мост написать нелегко. Хотя бы потому, что необходимо знать внутреннее устройство обоих систем.
"Внутреннее устройство" обеих систем знать нужно в любом случае.
B>Только тем, что не вводят никакого логического деления информации.
А оно нужно?
B>Про фортран не знаю. Про delphi, haskell известно. Это не мешает их строки преобразовать к виду "...." (в определенной кодировке) и пустить в поток.
Непонятно, о каком "виде" идет речь. Я вижу рисуночек из кавыче и точек. По нему совершенно непонятно, какие именно байты пойдут в поток.
Совершенно непонятно, будет ли это именно поток, или маршалинг будет выполняться неким другим способом.
B>Строка — как платформо-независимое средство выделения логических блоков информации в потоке. Вон тот же HTTP, SMTP.
Еще раз объясняю: строка — платформенно зависима. Учите матчасть. B>Предложите другое. И чем "байты" у Вас отличаются от "строки".
Тем, что байты платформенно независимы. У них нет никакой кодировки, есть только порядок следования. Сокеты подразумевают два протокола общения: потоковый и датаграммный. В первом не предусмотрен способ указать границы сообщения, но это зачастую удобнее, потому что можно получать данные порциями другого размера, чем передавать.
S>>Откуда взялся байт-код? B>Это о том, как просто было бы налаживать локальное быстрое нативное взаимодействие, если бы все системы были скомпилированы в некий байт-код, который, в свою очередь, компилировался бы в нативную платформу. Мысли не более. К сокетам и текстовому обмену отношения не имеет.
Очень хорошо. Давайте изобретать джаву в другом треде.
S>>А в чем проблема, которую хочется решить? Я всё еще не понимаю, что будет делать предлагаемая платформа. send и recv уже есть. Дальше что? B>Я не предлагаю никакую платформу. B>Это рассуждение на тему: было бы здорово иметь доступ через сокет к функционалу ЛЮБОЙ системы. Не прилагая усилий со стороны клиента по написанию мостов.
Это невозможно. B>Т.е. чтобы разработчик системы, сразу сделал бы к ней "текстовый интерфейс".
Непонятно, почему "не прилагая усилий" ставится равным "текстовому интерфейсу". Вот, к примеру, есть текстовый интерфейс к мэйлбоксам — IMAP. И что, кто-то питает иллюзии что можно вот так сесть и "не прилагая усилий" сделать клиента к этому интерфейсу?
B>Вот и интересовал вопрос: почему разработчик не сделал, как он это мог бы сделать (протоколы), насколько просто взаимодействовать через такой интерфейс.
Пока не видно никакого упрощения. Разработчику один хрен пришлось бы изучать "устройство системы", чтобы понять, какие сообщения эта система может принимать. А потом писать мост, который будет принимать вызовы в "родном" для исходной платформы виде и маршалить их через этот протокол. Текстовость/нетекстовость протокола — вопрос вообще десятый.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
