Перехожу к уведомлениям, напомню, что рассматриваю:
- Что надо задать в коде Арки-клиента
- Что надо задать в коде Арки-сервиса
- Что надо задать в схеме
- Что надо добавить в язык Арвиль
- Пример кода
Практически все, что можно сказать об уведомлениях, распространяется и на запросы. Но пока сосредоточусь на уведомлениях.
Итак, сервис посылает уведомление (через верстак), клиент его получает и обрабатывает. Уведомления именованные, то есть сервис может отправлять несколько разных уведомлений с указанием имени, а клиент должен подключится к получению уведомления с таким именем.
1. Что надо задать в коде Арки-клиента:
- похоже, что только метод, принимающий уведомления (приемник), так как подключение задается в схеме.
Но есть пара существенных вопросов. Первый, надо ли как-то выделять «приемник» для того, чтобы в процессе подключения сборщик мог видеть, куда можно подключить? Кажется не обязательно. Впрочем, на этот вопрос не надо отвечать прямо сейчас, пока нет IDE для сборки. И ответ на него косвенно зависит от ответа на следующий вопрос.
Второй, какая сигнатура у приемника? Очевидно, что у приемника не может быть выходных параметров (см. Тривиль 4.11.1. Параметры), и, возможно, типа результата. Хотя тип результата может быть, хотя будет игнорирован. Но лучше проверить и запретить.
Что касается параметров, то есть два пути: ленивый и хороший.
Ленивый. Сигнатура приемника (и, соответственно, передатчика) всегда:
фн (аргументы: …*)
То есть передать можно последовательность полиморфных аргументов. Это «лениво» с точки зрения реализации взаимодействия, но в каждом приемнике придется разбирать количество и типы аргументов.
Хороший: любое количество входных параметров любого типа. Например:
фн () // без параметров
или
фн (строки: []Строка, имя-файла: Строка) // например, для сохранения текста
Реализация хорошего способа сложнее, но использование удобнее. Так что я собираюсь делать «хороший» вариант.
Как это влияет на ответ на первый вопрос? Если сигнатура не фиксирована, то очень многие методы потенциально могут быть приемниками. И тогда я не вижу смысла особым образом отмечать потенциальные приемники, разве что в случае, если какой-то метод предназначен (по замыслу архитектора/разработчика) быть приемником. Впрочем, тут практика покажет. В Вире таких пометок не было.
2. Что надо задать в коде Арки-сервиса:
Для ленивого пути (см. выше) можно ничего не задавать и использовать отправку уведомления через верстак, например:
верстак.уведомить(«имя уведомления», параметры)
А для хорошего к коде что-то надо написать, чтобы задать сигнатуру уведомления, то есть, в коде сервиса должно быть описание, например, такое:
уведомление Закончилась операция(код-операции: Строка)
И далее, в операторной части, вызов — отправка уведомления:
Закончилась операция(«такая операция»)
Но увы, этого не достаточно, так как здесь не задан верстак, через который отправляется уведомление. А это нужно, например, для сборных арок. Для того, чтобы указать верстак нужно делать какой-то синтаксис, например:
уведомить Закончилась операция(«такая операция») через верстак
И тут сразу вопрос — а надо ли отправлять одно уведомление через разные верстаки? Или верстак достаточно указать в описании уведомления? Очень может быть, но надо подумать.
Постоянная ссылка
А у меня вот такой вопрос, может быть несколько поперек.
А вы не рассматривали уведомления как часть протокола?
Используя физическую аналогию «соединительного кабеля» я прикидывал, что «один их проводников внутри кабеля может служить для передачи каких-то обратных сигналов, не в обычном направлении». То есть, в рамках интерфейса могут быть сгруппированы разные способы взаимодействия сервера и потребителя:
1. Синхронные вызовы сервера — с приостановкой, активацией и передачей потока управления в сервер (call)
2. Асинхронные запросы — с приостановкой выполнения и ожиданием ответа (async call)
3. «Долгоиграющие» потоки данных, которые клиент может выкачивать, сам управляя интенсивностью передачи (stream)
4. Уведомления от сервера, которые могут прийти неожиданно и вызывают новую активацию потока исполнения в клиенте (async event)
5. …?
6. Вложенные именованные интерфейсы, как структурированный кабель, у которого может быть внутри несколько групп проводников с разным назначением.
Пока писал предыдущий абзац, много мыслей было по поводу того, что это неаккуратная классификация и намешано много аспектов — семантика, потоки исполнения, инициатива, etc.
Но вопрос главный остается прежним — почему уведомления у вас это не часть «протокола», если я верно понял?
К слову, в том же C# в интерфейса есть event тоже.
Вопрос степени динамичности, формата уведомлений, и способа реализации — конечно, тут вторичен.
Постоянная ссылка
> почему уведомления у вас это не часть «протокола»
Вопрос очень правильный и я об этом думал. Пока не пришел к решению. Как нам говорили старшие товарищи: «чтобы объединиться, мы должны сначала решительно и определенно размежеваться». Пока я вижу, что есть сильные/слабые взаимодействия и надо с ними сначала разобраться.