ищется протокол удалённого вызова процедур

достаточно словосочетаний для идентификации любого объекта

То есть существование судов бессмысленна? Все однозначно на момент подписания договоров?

Так именно это «постановщику» и твердят в каждой его шизофренической теме. Но больной упирается и выплевывает таблетки.

Все однозначно на момент подписания договоров?

Ежели обе стороны при составлении договора этого хотят, то да.

при этом пользуясь словами «интерфейс», «сокет», «пермиссивный» и т.д.

Про Thrift - правда ли, что проблемы с документацией?

Ну, збс теперь. Пересечение настолько несущетвенное, что всерьёз назвать это сабсетом HTML нельзя, оно может быть вообще случайным.

Данный файл корректно открывается любым браузером HTML, значит содержимое файла является сабсетом.

Урежешь до минимально необходимого для твоего приложения, может получиться так, что готовая библиотека такое не переварит.

Если используется подмножество протокола, то зачем готовая библиотека? Вот если мне надо отобразить упомянутый сабсет HTML, то ручной парсинг будет на несколько порядков быстрее и требовать меньше памяти, чем, например, WebKit.

И в этих договорах должен по умолчанию подразумеваться пункт

0) Любые споры решаются внесудебном порядке - стенка на стенку

TLV - понял, как вариант. Я уже изобрёл LV, а про T, видимо, ещё не успел :)

и числа только прописью, нельзя использовать арабские цифры

По логике Аристотеля «подмножество» != «сабсет»

аристотель бы тебе в рот нассал, логик.

Так там целеполагание, как я понял, другое. На одной стороне плюсы, на другой стороне какой-то сумрачный велосипед. Под сумрачный велосипед пишется библиотека, а на для плюсов можно взять готовую.

отрадно смотреть, как два пятизвездочника обсуждают протокол html.

два пятизвездочника

Кто второй?

не знаю, я в глаза долблюсь.

Я логику учу на ЛОРе, там хорошо объясняют про «логику Аристотеля», и про Карла, Маркса, Фридриха и Энгельса.

Под сумрачный велосипед пишется библиотека, а на для плюсов можно взять готовую.

Если протокол достаточно прост, то лучше написать свою. Как в примере про HTML, DIV и WebKit.

Если заняться больше нечем, то конечно.

не уверен, что аристотель физически смог бы нассать в рот всему лору, но желание такое наверняка бы испытал.

Если протокол достаточно прост, то

надо использовать встроенный в язык менеджер пакетов: npm, cargo, …

Если заняться больше нечем, то конечно.

Весь вопрос в соотнесении расходов рабочего времени.

Есть два языка. Под один есть библиотека, но минимальная реализация протокола для неё занимает 700 строк (условно-независимых от языка). Минимальная реализация необходимого подмножества протокола занимает 300 строк. Тогда использование библиотеки стоит 700 строк, а её неиспользование стоит 600 строк. Выгоднее не использовать.

надо использовать встроенный в язык менеджер пакетов

Он же не в язык, а в систему сборки встроен. Или что сказать хотел?

стоит 700 строк

Выгоднее не использовать.

Зарплату платят за количество строк написанных ватсапе! Вообще выпал из реальности!

Я знаю придурков, которые писали собственный парсер YAML на питоне и распилили на этом две недели.

Я знаю придурков

Не придурки, а реальные пацаны. Раз «логику Аристотеля» отменили.

и распилили на этом две недели.

Если им это оплатили, то придурки таки не они.

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

Я не заметил в hprose типа «указатель на удалённый объект». Его нет? И я бы не сказал, что он такой уж маленький - мегабайт исходников на го.

Также не вижу никакого подобия IDL, а как без него экспорты объявлять? Смотрю на thrift - уже ближе к теме кажется.

Не знаю что тебе выбрать, но grpc и protobuf отстой. Не бери их. Они генерирует говнокод, который не компилируется даже при обычном /W4 (аналог -Wall gcc, лишь самые базовые предупреждения)

При том не только в cc файлах, но даже в заголовочных файлах.

Проблема известная, авторам плевать.

Можно по этому понять какое это убожество.

8 лет вопросу на SO: https://stackoverflow.com/questions/13548478/are-there-some-better-ways-to-address-warnings-when-compiling-protocol-buffer-ge

Спасибо, не буду.

Это не так.

Вот всё, что есть: https://github.com/hprose/hprose/blob/master/3.0/serialization.spec.mediawiki

И RPC: https://github.com/hprose/hprose/blob/master/3.0/rpc.spec.mediawiki

Указатели есть только на то, что передаётся. Если нужен указатель, на что-то внешнее, то это обычное целое число.

Если нужны именно указатели на объекты, то указатель добавляешь в структуру класса.

мегабайт исходников на го.

273KB на JS https://github.com/hprose/hprose-js/blob/master/dist/hprose.src.js вместе с комментариями и реализацией Map.

Также не вижу никакого подобия IDL, а как без него экспорты объявлять?

https://github.com/hprose/hprose/blob/master/3.0/rpc.spec.mediawiki#Function_List

Эти два документа я посмотрел (и даже китайский автоперевёл - там вроде то же самое).

Нифига себе, значит js в 4 раза плотнее го? Но Оберон ближе к Го, чем к JS.

Если нужен указатель, на что-то внешнее, то это обычное целое число.

Это не целое число, т.к. нужно отслеживать время жизни и принимать обратно только реально существовавшие указатели, с учётом их типа.

Не, это протокол для динамической публикации API, но ничего не говорит о том, как его описать и как сгенерировать код обвязок. Особенно, как сгенерировать его из существующих исходников (а-ля SWIG)

Там всё про граничные случаи невалидных данных. Если ты там и гененируешь, и парсишь JSON, то ничего такого туда в принципе попасть не может. Только если руками делать кривой JSON.

Не, это протокол для динамической публикации API, но ничего не говорит о том, как его описать и как сгенерировать код обвязок.

Так это от языка зависит. Для Java вот: https://github.com/hprose/hprose-java/wiki/Hello-World

Для C++ есть только клиент (на сервер, видимо, рефлексии не хватило): https://github.com/hprose/hprose-cpp/blob/master/tests/main.cpp

Ну а на клиентской стороне только динамически тогда можно вызывать, без статической проверки. Не есть хорошо. В идеале из серверного кода (заголовочника) генерируется IDL, а из него - обвязки для клиента на любом языке, к-рые предоставляют на клиентской стороне данное API. Так сделано в SWIG для случая, когда сервер - C++

У меня и библиотеки JSON нет пока что. Когда я её напишу, будет ещё один экземпляр тех же грабель, поскольку другие пользователи этой библиотеки попадут в те же граничные случаи (которые проистекают из самого стандарта). Это, конечно, жизнь, но всё же слегка демотивирует.

В идеале из серверного кода (заголовочника) генерируется IDL, а из него - обвязки для клиента на любом языке, к-рые предоставляют на клиентской стороне данное API.

Тогда HPROSE не подходит. Там предполагается, что API не вкомпилируется в клиента. Можно сделать генератор, но готового нет.

JSON в 99% случаев пишется машиной для машины. Ты знаешь много библиотек, которые генерируют JSON с лишними запятыми, незакрытыми скобками и числами, не влезающими в double? Такой JSON может придти только при формировании его руками и единственная твоя задача это не упасть на каком-нибудь переполнении буфера, а либо распарсить, либо выдать ошибку. Если юзер умышленно сделал невалидный JSON, то он не обидется, если в ответ на запрос сервис сделает не то, что он хочет. ССЗБ же.

Все разногласия из статье - по поводу JSON, которые этими самыми инструментами из статье сгенерировать нельзя.

Говорят, философская ссанина самая дорогая.

Гугловый протобаф же. Кстати, а если паскалевы структуры? Насколько они платформозависимы?

Не дороже, чем дерьмо художника.

Сделать на коленке, это несложно.

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

Я так в том числе питон с плюсами вяжу, причём без сокетов, через стандартный ввод/вывод, а под него можно SSH например подложить.

т.к. придётся портировать на новый язык, в котором ничего нет

CORBA

смищно

Я просто пытаюсь понять, библиотеки в принципе полезны, или вообще всё надо делать на коленке? Ведь немало же функционала в такой штуке. Где грань-то?

хранить ссылки на удалённые объекты

apache thrift

ЕМНИП в Thrift не было раньше явного понятия удаленного об’екта. Можно было только адресоваться к конкретному серваку через адрес сетевого уровня, т.е. если нужны разные «об’екты», надо для каждого создавать свой рантайм сервер и вешать его на уникальный сетевой адрес. Но в Thrift IDL нет такого понятия как «ссылка на обьект», которую можно передавать как типизированный аргумент. Хотя, может быть я уже безбожно устарел…

У меня есть такая проблема, как чрезмерное обобщение. Если мне json не нравится, то я в целом начинаю искать, а что ещё вместо него есть. Понятно, что это вкусовщина, но поскольку в моём языке json-а нет, то и пусть не через меня это зло туда придёт. А если где-то есть вменяемая альтернатива, так я её буду везде совать.

Да, что-то в доке нету. Что ж оно всё такое убогое-то :( Или имеется в виду, что я сам должен сформировать какие-то «хендлы», которые будут вместо указателей?

ссылки на удалённые объекты

какая-то компактная многоязычная библиотечка

Очень плохо сочетаются.

Можно посмотреть msgpack-rpc (очень плохо документирован)