roboforum.ru

Казалось-бы надо сделать функции, которые облегчат жизнь программисту...

Для этого есть хранимые процедуры кстати, так что этот механизм не забыт.

Задачу, которую решает предложенный RPC можно обобщить так:
"Программа на хост компьютере взаимодействует с программой на борту"

Давайте еще раз обобщим и скажем, что это можно реализовать на машине Тьюринга... не надо ничего лишний раз обобщать вот есть описание (http://ru.wikipedia.org/wiki/Remote_Procedure_Call) именно эту задачу мы и решаем. Вызываем одни функции из адресного пространства других. Все.

С моей точки зрения наличие явного диалогового режима позволяющего взаимодействовать с бортовой системой является основой, а механизм RPC есть прослойка между пользовательской программой и диалоговым взаимодействием и может быть реализована в удобном для программиста виде (в виде библиотек с базовыми возможностями или в виде классов или DLL или еще как-то)

Это заблуждение, т.к. RPC не является просто прослойкой. Прослойка это если вы вручную реализовали диалоговой режим, а потом вывели интерфейс к нему через DLL. Здесь же все это происходит автоматически и реализуется обмен и строится интерфейс.

Вы что-то совсем в другую степь ушли.

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

Несмотря на то, что набор функций строго определен, это не избавляет вас от отладки этих функций в процессе написания SQL-сервера (если вы захотите реализовать его на МК, например). Разговор про отладку мне непонятен, чем по-вашему принципиально отличается "послать строку и получить в ответ строку" от "послать аргументы и получить в ответ результаты"? Вас смущает невозможность работы в терминалке?

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

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

2mandigit: ИМХО всё просто - вот есть у вас робот на нём 2 функции double GetRange() для получения в метрах дистанции с дальномера и SetMotorSpeeds(double speed_left,double speed_right) - сколько времени вам нужно будет чтобы обеспечить работу с этими функциями с ПК? Тут я так понимаю минуту-полторы, а вам надо будет парсер писать свой. Далее потребуется добавить пару команд - и тут снова полторы минуты, а вам скорее всего придется додумывать свой парсер, т.к. выяснится, что вы его написали неуниверсально и т.п.

Ситуация станет на порядок круче если Виталий добавит в свой RPC определение ошибок при передаче + контроль доставки.

Начну с конца:
опять упоминается хитрое слово "автоматически"
Если мы на стороне ПК предоставляем библиотеку, которая формирует строки при вызове соответствующих функций - это автоматически?

насчёт гибкость, независимость, прозрачность - ничего такого в помине нет.
Вот представьте себе, как система будет развиваться в динамике: сделали базовый набор функций там и сям, выпустили, где-то кто-то что-то добавил - получилась еще версия, потом еще и еще. Если вы будете вести общение не через терминал, а через специально обученную программу, которая будет интерпретировать содержимое обмена, то как она будет понимать то, о чем не знает? Если версия на борту обладает каким-то функционалом, появившемся в процессе эвалюции, о котором "дешифратор" на стороне хоста не в курсе?
О какой гибкости может идти речь, какая прозрачность? какая независимость?

SQL я привел в качестве примера, который имеет много общего с задачей управления.

Конечно совместимость не 100%, но найдите пример лучше и будем ориентироваться на
него.


2Dead
В твоем (не против) примере:
Send("getrange")
range = stoi(Recive())
Send("SetMotorSpeed " & double speed_left & "," & double speed_right)

насчёт добавления команд: как-раз парсер пишется несложно и новые команды добавляются - код вообще менять не нужно. А вот как менять код RPC для меня загадка - появилась новая функция и что? Используем какой-то новый механизм регистрации, описания параметров?
А ошибки перидачи и контроль доставки - это вообще не уровень RPC, эти вопросы решаются на транспортном уровне.

PS Дайте кого-нибудь в союзники, а то втроем навалились

mandigit писал(а):как-раз парсер пишется несложно и новые команды добавляются - код вообще менять не нужно

Мы тоже когда для ORFA писали парсер так думали

парсер писать очень сложно, особенно если в нескольких параметрах подразумевается разный синтаксис записи
например при вызове конфигуратора сетевого адреса мы на одном и том же месте в параметрах мы можем иметь
ip aaa.bbb.ccc.ddd
локальное имя
деменное имя (FQDN)
сеть с маской aaa.bbb.ccc.000/xxx.yyy.zzz.ttt

в общем когда начинаешь проверять все варианты ещё и пытаясь их отличить от возможных на этом месте команд ...
ой не просто это

+1, я тоже уверен парсер - это ни разу ни просто.

Не надо смешивать в одну кучу сложный язык и простую грамматику.
Решаемая задача требует только 2 метода: передача параметров, прием параметров.
Парсер в этом случае сложностей не представляет.
А обсуждение парсера к примеру языка СИ выходит за рамки обсуждаемой темы.

Парсер, о котором говорю я умеет следующее:
принять строку типа <имя функции> параметр1, ... ,параметрN
его задача состоит в разделении параметров в соответствие с используемым разделителем и передача функции ссылки на массив указателей на переданные параметры
обратная задача тоже сложной не является:
<результат работы> параметр1, ..., параметрN
и позволяет интерпретировать работу как визуально, так и программой.