Пусть у нас есть несколько программ/библиотек, написанных на разных языках, под разные платформы.
Как следствие они не совместимы между собой. Например, 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, ...), которые тянут одеяло на себя, которые не заменяют С/С++, достаточно далеко уходя от аппаратной платформы, которые добавляют кучу специфичного своего, и в которых большая часть библиотек/алгоритмов пересекается.
Здравствуйте, 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>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, 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?
