Комментарии 4
Возможно из набора статей можно было бы сделать доклад на Scheme Workshop. Дедлайн 2020 уже завтра, но статья ждала 5 лет этого комментария, наверное и 2021 года подождёт.
На Scheme Workshop хочется идти с концептуальным докладом. Эти статьи по большому счету особо нового не несут, всего лишь scheme для .net. За 5 лет по этой теме у меня произошло много интересного, были изучены разные интерпретаторы scheme под .net, даже Microsoft опубликовал свой интерпретаор схемы. Почти сразу после публикации статей я начал разрабатывать свои интерпретаторы схемы, для использования в качестве встраиваемого языка, и что самое интересное в качестве RPC и не только. S-expression как формат доставки сообщений показал себя очень интересно, поскольку может описывать произвольную структуру данных с одной стороны, а с другой очень легко парсится, и к тому же компактен, что уменьшает оверхед при передаче. Даже первая версия проекта Ogam показывала отзывчивость выше, чем у мейнстримных решений SOAP, REST. Кроме этого, на принимающей стороне используется scheme интерпретатор, что позволяет не только вызывать процедуры но и комбинировать их без передачи временных результатов на клиента, например, отфильтровать или конвертировать множество и уже результат вернуть на клиента. Так же экспериментировал с сериализацией .net объектов(таблицы хранения примитивов и лисповский cons для связи) для сохранения в реляционной базе, что очень удобно для хранения произвольных структур, с возможностью select'а по ним. Сейчас, в новой версии я иду к модели акторов + scheme, суть понятна, но сложнее сделать юзабильное и простое в использовании решение под .net. И вот с этим уже можно на Scheme Workshop, но это точно не раньше чем через год.)
Вы бросаете по сети только данные, сериализованые в S-Expressions, или у вас есть какой-то хитрый способ бросать замыкания?
Нет, замыкания не передаются, не вижу практического смысла и сложности реализовать это. Сервер реализует функции, а клиент их вызывает и получает ответ, по типу
Вот пример обмена:
В текущей версии s-exp передается в бинрном виде, это нужно, например, чтобы передавать файлы без base64, проще передавать строки, не нужно с экранированием заморачиваться, да и быстрее reader работает. Составные объекты, как экземпляры класса(DTO) преобразуются к виду (quote (...)), примитивы передаются как есть в бинарном виде.
Суть в том, что можно разорвать запрос/ответ и полуить нечто похожее на модель акторов, осталось только сделать удобный инструмент для работы с этим из C#. А вот как возвращать ответ, в принципе можно и через коллбеки, но опять же зачем сервер и так знает куда передать ответ?
(+ 1 2 3) => 6Вот пример обмена:
<< ((sd3-srv:Commit "b72dfef2338240eebd055edcabe376df" (quote ((Id . "39f5873a9838845a6150ed08ee6002d6") (ComplectId . "39f5873217153076485946b324ebb1ea") (User (Id) (UserLogin) (UserDomain)) (Stage (Id . "wo.handle.crop-passport") (Name . "")) (CreateDate . "02.06.2020 12:42:14.968") (ComplectRouteId . "tcb-short-offer.flow") (Tags ((Id . "39f5873a98678479238f985bfaaa819f") (Key . "skip") (Value . "WO-CROP.HANDLE-WARNING. Для request-id: 39f5873a4eaa78cd8e9528a2960ae8dd данных нет") (CommitId . "39f5873a9838845a6150ed08ee6002d6"))) (AttachCriteriaBindingIds #nil) (TargetStageId)))))
>> True
В текущей версии s-exp передается в бинрном виде, это нужно, например, чтобы передавать файлы без base64, проще передавать строки, не нужно с экранированием заморачиваться, да и быстрее reader работает. Составные объекты, как экземпляры класса(DTO) преобразуются к виду (quote (...)), примитивы передаются как есть в бинарном виде.
Суть в том, что можно разорвать запрос/ответ и полуить нечто похожее на модель акторов, осталось только сделать удобный инструмент для работы с этим из C#. А вот как возвращать ответ, в принципе можно и через коллбеки, но опять же зачем сервер и так знает куда передать ответ?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Практика IronScheme