Здравствуйте, Beam, Вы писали:

Re: Как собрать процесс воедино?

Автор: rsn81
Дата: 28.06.07

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 уже есть. Дальше что?

Здравствуйте, 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>Как следствие они не совместимы между собой. Например, Java — wxWidgets, Haskell — Prolog, VB — Smalltalk и т.д.
B>Иногда, хочется наладить взаимодействие между ними. Часто для этого пишут мосты.

Старый ответ: CORBA. Можешь заинтеропится хоть с мэйнфреймом, где крутится система на коболе.
Новый ответ: Enterprise Bus Architecture. Конкретнее — рекомендуется пристально взглянуть на AMQP. Можно связать географически распределенные системы, и использовать в качестве транспорта хоть голуюиную почту.

Если речь идет о взаимодействии на одной машине, то это, безусловно, COM под вендой, и, по всей видимости, dbus под Linux.

И не надо никаких мостов.

Здравствуйте, Beam, Вы писали:

B>Я действительно исходил из того, что мост написать нелегко. Хотя бы потому, что необходимо знать внутреннее устройство обоих систем.
"Внутреннее устройство" обеих систем знать нужно в любом случае.

B>Только тем, что не вводят никакого логического деления информации.
А оно нужно?

B>Про фортран не знаю. Про delphi, haskell известно. Это не мешает их строки преобразовать к виду "...." (в определенной кодировке) и пустить в поток.
Непонятно, о каком "виде" идет речь. Я вижу рисуночек из кавыче и точек. По нему совершенно непонятно, какие именно байты пойдут в поток.
Совершенно непонятно, будет ли это именно поток, или маршалинг будет выполняться неким другим способом.

B>Строка — как платформо-независимое средство выделения логических блоков информации в потоке. Вон тот же HTTP, SMTP.
Еще раз объясняю: строка — платформенно зависима. Учите матчасть.
B>Предложите другое. И чем "байты" у Вас отличаются от "строки".
Тем, что байты платформенно независимы. У них нет никакой кодировки, есть только порядок следования. Сокеты подразумевают два протокола общения: потоковый и датаграммный. В первом не предусмотрен способ указать границы сообщения, но это зачастую удобнее, потому что можно получать данные порциями другого размера, чем передавать.

S>>Откуда взялся байт-код?
B>Это о том, как просто было бы налаживать локальное быстрое нативное взаимодействие, если бы все системы были скомпилированы в некий байт-код, который, в свою очередь, компилировался бы в нативную платформу. Мысли не более. К сокетам и текстовому обмену отношения не имеет.
Очень хорошо. Давайте изобретать джаву в другом треде.


S>>А в чем проблема, которую хочется решить? Я всё еще не понимаю, что будет делать предлагаемая платформа. send и recv уже есть. Дальше что?
B>Я не предлагаю никакую платформу.
B>Это рассуждение на тему: было бы здорово иметь доступ через сокет к функционалу ЛЮБОЙ системы. Не прилагая усилий со стороны клиента по написанию мостов.
Это невозможно.
B>Т.е. чтобы разработчик системы, сразу сделал бы к ней "текстовый интерфейс".
Непонятно, почему "не прилагая усилий" ставится равным "текстовому интерфейсу". Вот, к примеру, есть текстовый интерфейс к мэйлбоксам — IMAP. И что, кто-то питает иллюзии что можно вот так сесть и "не прилагая усилий" сделать клиента к этому интерфейсу?

B>Вот и интересовал вопрос: почему разработчик не сделал, как он это мог бы сделать (протоколы), насколько просто взаимодействовать через такой интерфейс.
Пока не видно никакого упрощения. Разработчику один хрен пришлось бы изучать "устройство системы", чтобы понять, какие сообщения эта система может принимать. А потом писать мост, который будет принимать вызовы в "родном" для исходной платформы виде и маршалить их через этот протокол. Текстовость/нетекстовость протокола — вопрос вообще десятый.