| |
| 2.6, Crazy Alex (ok), 01:24, 27/02/2015 [^] [^^] [^^^] [ответить]
| +1 +/– |
 А что здесь такого? Можно подумать, что нынешние запросы к облачным сервисам - это не RPC. Только обычно - это JSON или HTML-формы без формального описания. асинхронность и ошибки, опять же, все давно обрабатывать научились...
| | |
| |
| |
| 4.22, Crazy Alex (ok), 15:00, 27/02/2015 [^] [^^] [^^^] [ответить]
| +/– |
И где ты видел облачные API, основанные на сообщениях? Везде именно RPC, только не формализованный толком - от социалок до интерфейса амазоновских облаков.
| | |
| |
| 5.27, yet another anonymous (?), 18:17, 27/02/2015 [^] [^^] [^^^] [ответить]
| +/– |
Кто-нибудь из столь уверенно высказавшихся имел дело с эксплуатацией скажем, CORBA-, based сервиса с неопределенным количеством клиентов? (А еще лучше --- с трафиком выходящим за пределы корпоративной сети).
| | |
| |
| 6.28, Crazy Alex (ok), 18:28, 27/02/2015 [^] [^^] [^^^] [ответить]
| +1 +/– |
Ну, CORBA - это вообще отдельный разговор. Интересно, хоть где-то ещё жив этот монстр? Нынче решения проще на порядок.
| | |
|
|
|
|
| 2.14, Нанобот (ok), 12:09, 27/02/2015 [^] [^^] [^^^] [ответить]
| +/– |
 никто не заставляет тебя использовать это в глобальных сетях, не переживай ты так
| | |
|
| 1.4, Аноним (-), 00:52, 27/02/2015 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– | |
> предлагаемый инструментарием Protocol Buffers.
А просто слать по сети вот это вот - им показалось слишком простым, да? :)
| | |
| |
| 2.7, Crazy Alex (ok), 01:25, 27/02/2015 [^] [^^] [^^^] [ответить]
| +/– |
Если gRPC уже используется внутри гугла - скорее всего в нём есть какие-то плюсы, нет?
| | |
| |
| 3.16, Kodir (ok), 12:38, 27/02/2015 [^] [^^] [^^^] [ответить]
| +/– |
 Не факт. Силовое решение вопроса - не гарантия идеальной системы. Думаете, не силовое? Тогда там сейчас был бы десяток разных сервисных протоколов, включая WCF и Corba.
| | |
| |
| 4.23, Crazy Alex (ok), 15:02, 27/02/2015 [^] [^^] [^^^] [ответить]
| +1 +/– |
То, что гугл - один из технологических лидеров - для меня достаточное основание, чтобы считать, что технические решения там обычно выбираются эффективно.
| | |
| |
| |
| 6.34, Crazy Alex (ok), 04:27, 28/02/2015 [^] [^^] [^^^] [ответить]
| +1 +/– | |
А что такое "русский софт"?
Софт, в разработке которого принимали участие разработчики из России - понятно, такого полно. Даже софт, в котором большая часть написана разработчиками из России, вроде nginx - тоже понятно, хотя такого уже очень мало и мне он действительно не нужен. А "русский", "китайский" или "американский" софт - не знаю такого.
| | |
| |
| 7.35, Аноним (-), 19:50, 28/02/2015 [^] [^^] [^^^] [ответить]
| +/– |
1C же! :) Если не знаешь - повезло, все кто узнал - сгорят в аду :))))
| | |
|
| 6.36, Аноним (-), 19:51, 28/02/2015 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Лидер, ха!
> Может быть вы и русским софтом не пользуетесь?
В оригинале - "один из технологических лидеров"!
И нравится тебе это или нет - это так. А "руссийсофт" - это стыдоба 1С. Больше ничего нет.
| | |
| |
| 7.45, Анон1 (?), 18:35, 10/03/2015 [^] [^^] [^^^] [ответить]
| +/– |
Сиди и кури, пёс, если окромя 1С отечественных продуктов в области IT не знаешь
| | |
|
|
|
|
|
| 2.8, Тот самый с плаката (?), 02:25, 27/02/2015 [^] [^^] [^^^] [ответить]
| +4 +/– | |
Ты когда-нибудь распределённые сетевые приложения писал? При достижении определённой сложности взаимодействия компонентов в коде либо самопроизвольно зарождается свой доморощенный аналог Protobuf (не всегда плохой, просто самописанный), либо выкидываются костыли и берётся Protobuf. Я участвовал в разработке двух таких систем для обмена телеметрией с производств (ничего особенного, просто потоки "событий" и "реакций" на эти события, даже без слишком жёстких требований по времени). Первый раз мы не без проблем выкидывали свои разработки и внедряли Protobuf в срочном порядке, когда на очередную итерацию нам принесли радость в виде необходимости "склеиться" с внешним вендором. К счастью, ребята на том конце были опытные и дружелюбные, помогли и советом, и кодом. Второй раз решили не выпендриваться, и взяли Protobuf сразу же. Оказалось, не зря -- создалась аналогичная ситуация, но на этот раз всё ограничилось обменом парой файлов и сертификатом.
А так да, можно и просто слать по сети. Через lo, например.
| | |
| |
| 3.9, Аноним (-), 02:40, 27/02/2015 [^] [^^] [^^^] [ответить]
| +/– |
Я про то что нафиг они какой-то HTTP/2 достаточно навороченный городили. Могли бы сразу слать протокол буферы свои с какой-нибудь совсем минимальной транспортной обвязкой.
| | |
| |
| 4.11, Тот самый с плаката (?), 03:50, 27/02/2015 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Я про то что нафиг они какой-то HTTP/2 достаточно навороченный городили. Могли бы сразу слать протокол буферы свои с какой-нибудь совсем минимальной транспортной обвязкой.
Потому что Protobuf -- это библиотека общего назначения для разработчиков, а HTTP/2 -- это конкретный стандартизованный протокол. Может быть HTTP/2 и можно описать в терминах Protobuf. Но зачем?
| | |
| |
| 5.13, Аноним (-), 12:02, 27/02/2015 [^] [^^] [^^^] [ответить]
| +/– |
> -- это конкретный стандартизованный протокол. Может быть HTTP/2 и можно описать
> в терминах Protobuf. Но зачем?
Скорее, зачем нужен HTTP/2 если есть Protobuf который один фиг натянули на него.
| | |
| |
| 6.30, Аноним (-), 22:28, 27/02/2015 [^] [^^] [^^^] [ответить]
| +2 +/– | |
>Скорее, зачем нужен HTTP/2 если есть Protobuf который один фиг натянули на него.
15% пользователей фейсбука считают что никогда не пользовались интернетом.
Protobuf это уровень приложения. HTTP/2 - Транспортный уровень.
| | |
| |
| 7.42, Аноним (-), 20:34, 28/02/2015 [^] [^^] [^^^] [ответить]
| +/– | |
> Protobuf это уровень приложения. HTTP/2 - Транспортный уровень.
Он как-то сильно наворочен для транспортного уровня и занимается кучей всякой дряни, явно не свойственной транспорту.
Ну вон например компрессия заголовков занимается сохранением состояния сессии (синхронные буфера локально и у ремоты же, с перекидыванием только дельты). Это уже ближе к управлению сессией ... при том на уровне приложения. Или вон например мультиплексироваие. Сделали как-то излишне навороченно, имхо.
| | |
|
|
|
| 4.26, Crazy Alex (ok), 15:13, 27/02/2015 [^] [^^] [^^^] [ответить]
| +/– |
Потому что этот HTTP/2 будет скоро везде. И логично сразу на него закладываться. А для RPC чем больше всего жестко стандартизировано - тем меньше потом проблем с интероперабельностью.
| | |
|
| 3.17, Kodir (ok), 12:45, 27/02/2015 [^] [^^] [^^^] [ответить]
| +/– | |
> Ты когда-нибудь распределённые сетевые приложения писал?
А ты хочешь выдать за опыт "все обе" своих системы?? Негусто...
Я вот тоже сторонник работы "без наворотов". Протобуф - ни бог весть какое откровение, всего-лишь тупо ЕЩЁ ОДНА библиотечка для сериализации. К тому же, требующая ЕЩЁ ОДИН язык для определения формата и создавая ЕЩЁ ОДНО "слабое звено" в виде отдельного файла, который требуется синхронизировать с нативным кодом. Оно надо?
Гугл - это студота, фик знает по каким критериям нанятая, поэтому нечего на них молиться.
JSON over TCP - у меня тоже есть опыт системы, где мне пришлось делать ровно НОЛЬ усилий для "описания формата", сохраняя при этом гибкость.
| | |
| |
| 4.25, Crazy Alex (ok), 15:11, 27/02/2015 [^] [^^] [^^^] [ответить]
| +/– | |
Если у тебя ноль усилий для описания формата - значит он не описан и у тебя нет никакой уверенности в том, что он обрабатывается хоть как-то аккуратно. Плюс - у тебя нет готовой документации для него.
А гугл - достаточно хорош технически, чтобы быть в лидерах. Не хочешь свои сравнимые (да хрен со сравнимостью - хоть как-то заметные) достижения предъявить?
| | |
| |
| 5.37, Аноним (-), 19:56, 28/02/2015 [^] [^^] [^^^] [ответить]
| +/– | |
> Не хочешь свои сравнимые (да хрен со сравнимостью - хоть как-то заметные) достижения предъявить?
Джентльменам верят на слово ... (С) Kodir же сказал ... :)
| | |
|
| 4.41, Аноним (-), 20:30, 28/02/2015 [^] [^^] [^^^] [ответить]
| +/– | |
> JSON over TCP - у меня тоже есть опыт системы,
Капитан Очевидность намекает что случаи бывают разные. JSON и ProtoBuf весьма разные. Протокольные буфера имеют смысл там где надо быстрый парсинг и компактное представление.
Вон OSMщики как получили XML весом в 250 гигабайтов (!!!) и обнаружили что тулзей для работы с XML такого размера просто не бывает - быстро перешли на .pbf, базированый на protocol buffer'ах.
| | |
|
|
|
| 1.15, Kodir (ok), 12:35, 27/02/2015 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– | |
> ...предлагается использовать язык описания интерфейсов (IDL)
Извините, ребята, мы это уже проходили - к 19 стандартам добавление 20-го!
JSON уже умеет сериализовать нативные структуры БЕЗ использования ещё одной точки инконсистентности, так что поделки гугловских студентов идут нафик.
| | |
| |
| 2.19, Аноним (-), 13:39, 27/02/2015 [^] [^^] [^^^] [ответить]
| +3 +/– |
> JSON уже умеет сериализовать нативные структуры БЕЗ использования ещё одной точки инконсистентности,
> так что поделки гугловских студентов идут нафик.
JSON ничего не умеет, это формат, причем текстовый.
| | |
| 2.24, Crazy Alex (ok), 15:08, 27/02/2015 [^] [^^] [^^^] [ответить]
| –1 +/– | |
А потом под этот JSON предлагаешь руками делать обработчике во всех 100500 системах, которые должны понимать твои структуры данных - это, конечно, ни разу не источник неконстистентности и ошибок.
В плане RPC я знаю только один принцип - он может быть любым, но стандартизированным. Есть IDL для формата сериализации - хорошо. Жестко прибит нижележащий протокол - ещё лучше. Четко определено, куда даолжны идти запросы и как они дистпетчеризуются - вообще отлично. Это значит, что это всё не надо будет продумывать самим и потом нарываться на то, что у пратнёров всё не так.
А так - ну я бы сам MsgPack предпочел буферам - но хрен бы с ним, лучше буферы везде, чем нестандартные поделки
| | |
| 2.29, Нанобот (ok), 20:03, 27/02/2015 [^] [^^] [^^^] [ответить]
| +/– |
вообще-то сериализация в json на порядок медленнее protocol buffers. или на два порядка, если реализация кривая
| | |
| |
| 3.39, Аноним (-), 20:27, 28/02/2015 [^] [^^] [^^^] [ответить]
| +/– |
> вообще-то сериализация в json на порядок медленнее protocol buffers. или на два
> порядка, если реализация кривая
А еще бинарные данные в нем сереализовать ну вообще сакс.
А так - можете взять .pbf файл от OSMщиков и конвертануть в json. И посмотреть как их 20 гигов превратятся в 100.
| | |
| 3.43, Аноним (-), 21:26, 28/02/2015 [^] [^^] [^^^] [ответить]
| +/– |
Для сведения порадок это 10 крат, 2 порядка 100 крат, если увас протобаф работает в 100 раз быстрее парсера json то у вас парсер json явно не на си написан.
| | |
| |
| 4.44, Crazy Alex (ok), 02:18, 01/03/2015 [^] [^^] [^^^] [ответить]
| +/– |
Это вы не пытались _большой_ JSON парсить. Там скорость падает как-то совершенно нелинейно обычно
| | |
|
|
| 2.31, Аноним (-), 22:33, 27/02/2015 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> JSON уже умеет сериализовать нативные структуры
Бумага умеет писать стихи и неплохие, скажу я вам.
> БЕЗ использования ещё одной точки инконсистентности,
Я знаю карате кун-фу тейквандо и еще пару страшных китайских слов.
> так что поделки гугловских студентов идут нафик.
Вы явно не представляете распространенности protobuff. Для затравки: 3% мирового трафика минимум - это сообщения в формате protobuff.
| | |
|
| |
| 2.40, Аноним (-), 20:28, 28/02/2015 [^] [^^] [^^^] [ответить]
| +/– | |
> У меня rpc ассоциируется с бэкдорами, благодаря мс...
RPC == Remote Procedure Call. И все-таки нечто бэкдорическое в этом есть, по определению :)
| | |
|
|
