Здравствуйте, Sinclair, Вы писали:
_>>Ну что за детских сад? Вот давай ты попробуешь реализовать в стиле REST например тот же самый потоковый протокол Тинькова информации с биржи. Т.е. вот мы подключаемся; подписываемся на информацию о 5 акциях; нам идёт в ответ непрерывный поток этой информации; далее в какой-то момент мы хотим ещё и о какой-то 6-ой акции получать информацию и изменяем свою подписку; и после этого получаем уже поток с информацией о 6 акциях. И всё это конечно в рамках одного соединения. Ну и как ты это сделаешь? S>Сделаю POST, в тело которого запишу список 5 акций. Для простоты — в line-delimited JSON. В ответ нам начинает ехать поток обновлений в какой-то кодировке. S>Для простоты — line-delimited JSON. S>Поток никогда не закрывается. Ни туда, ни обратно. Всё. S>Тут, конечно, нарушены некоторые принципы REST, но в целом всё работает
Так это ты описал только начало из указанного мною сценария. А как 6-ую акцию то включить в поток в процессе работы? )
_>>И? Эти данные уже давно стухли. S>Ну как это "стухли"? S>Вот у меня есть 500 инструментов. Обновляются по разному. Кто-то раз в час, кто-то раз в секунду. Связь на 10 секунд пропала. Мне теперь надо перевычитать цены для всех 500? Изменилось-то за это время может быть 40 позиций. Опять же — как мне убедиться, что между моментами "я прочитал все цены" и "я начал ловить поток изменений" не было потерянных изменений?
А вот как раз для этого и существует функция (не потоковая) "получить текущие цены". Та самая, которую ты хотел зачем-то оптимизировать на отправку только изменений (сломав тем самым нужную функциональность).
_>>Так я вроде приводил графики (причём даже не свои, а какие-то дотнетные), но ты сказал что нарисовать всё что угодно можно... S>Это потому, что непонятно, какая задача решалась. Я вот показываю примеры, в которых при неустойчивой связи RPC будет гораздо хуже по трафику, чем REST.
Какие ещё примеры ты показал? Что в 90-ые годы была польза от возможности докачать большой статический файл при обрыве связи? Это правда... Только какое это имеет отношение к современным API, работающим в современных сетях?
_>>И снова детский сад? Вот как будто бы ты не знаешь как решается данный вопрос. Что есть две стандартные стратегии: или текущее соединение блокирует все новые или же любое новое соединение выкидывает предыдущее. И в разных задачах используется или один или второй подход. S>Здорово. То есть теперь мы не можем посмотреть одну и ту же камеру с двух компьютеров.
Не смотреть камеру, а иметь доступ к интерфейсу управления. Ты вот видел когда-нибудь, чтобы например к одному дрону можно было подключиться с двух контроллеров? Может это тоже недостаток продукта? )))
S>Смотрите, как быстро вы закапываете свой продукт Меня всегда изумляли ситуации, когда люди намеренно делают продукт хуже, вместо того, чтобы немножко подумать.
Да, да, я уже прямо представил, что твой дрон управляемый по OData одновременно сотней операторов, был бы просто хитом. )))
Здравствуйте, alex_public, Вы писали:
_>Так ты не ответил, какой там 2-ой пункт из требований REST? И как это пересекается с твоим пониманием REST "Именно что понимается хранение состояния сервером"? )))
Я подозреваю, что вы про state.
Ну так нормально и пересекается — я же написал вам пример про рейс.
_>Прикинул вероятность побитового совпадения двух произвольных цветных картинок размером 200*80px и в очередной раз оценил твоё умение проектировать системы. )
А вы каким способом эту вероятность оцениваете? Просто возводите 2 в степень -(16000)?
Тогда да — вам стоит поучиться проектировать системы. Потому что входные данные ни в какой задаче не бывают равновероятными.
Например, если результат запроса стоит в подписи у участника активного форума, то одна и та же картинка может быть запрошена несколько тысяч раз.
_>Да, люди очень хорошо научились раздавать статические файлы.
Почему же статические? Число Pi бесконечно — ни в какой файл его не запишешь.
_>О, т.е. теперь уже оказывается, что можно решить задачку на REST и без дополнительного железа? Или что? )))
Нет, оказывается, что вы по-прежнему не понимаете, как делаются нормальные продуктовые решения.
Датчик нулевого положения привинчивается к камере для того, чтобы на сервере была возможность получать текущее состояние.
Ну, то, которое вы полагали невозможным без дорогостоящего енкодера.
Дальше, поскольку мы понимаем, что камера поворачивается не мгновенно, у нас нет возможности моментально выполнить любой запрос типа "повернись на северо-запад".
Нужен какой-то способ этим управлять — поэтому в протоколе у нас будет два положения: текущее истинное и целевое. Первое меняет сервер, второе — клиент.
В вашем RPC-подходе клиент может успеть запихать в канал 1000 сообщений "направо", особенно если сеть локально взглюкнуло и возникла задержка передачи.
Отменить эти сообщения клиент не может — он будет вынужден ждать, пока камера всё это прокрутит и успокоится, чтобы начать снова управлять положением.
А в REST подходе, даже если я попросил направить на северо-восток, но потом передумал и решил направить на восток, сервер не будет совершать лишних движений.
_>Не слышал про такой протокол, как DML... https://en.wikipedia.org/wiki/Data_manipulation_language
_>Я правильно понял, что теперь у нас и SQL плохой и устаревший? )))
Для распределённых систем — да. Никто в здравом уме SQL через океан не гоняет, и наружу недоверенным клиентам не выставляет. Вы же не могли проспать переход от client-server к трёхзвенке?
_>Я правильно понял, что этот мертворождённый уродец, является твоим идеалом? )
Нет, там можно ещё улучшить. Но ODATA уже очень даже неплох. Как минимум, лучше большинства RPC поделок.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, alex_public, Вы писали:
_>Так это ты описал только начало из указанного мною сценария. А как 6-ую акцию то включить в поток в процессе работы? )
Так и включить. Канал-то не закрыт. Дошлю ещё строчку line-delimited JSON.
_>А вот как раз для этого и существует функция (не потоковая) "получить текущие цены". Та самая, которую ты хотел зачем-то оптимизировать на отправку только изменений (сломав тем самым нужную функциональность).
ИИИ? Функция вернула результат на момент T0. Поток начал ехать в момент T0+dT.
Что с изменениями, которые (возможно) произошли за dT?
_>Какие ещё примеры ты показал? Что в 90-ые годы была польза от возможности докачать большой статический файл при обрыве связи? Это правда... Только какое это имеет отношение к современным API, работающим в современных сетях?
Современные сети — это, в том числе, и GPRS на ходу из автомобиля, который едет по городу с туннелями и развязками.
_>Да, да, я уже прямо представил, что твой дрон управляемый по OData одновременно сотней операторов, был бы просто хитом. )))
Естественно. Был бы именно что хитом. Но пока технической возможности реализовать именно дрон нету.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, alex_public, Вы писали:
_>>>И снова детский сад? Вот как будто бы ты не знаешь как решается данный вопрос. Что есть две стандартные стратегии: или текущее соединение блокирует все новые или же любое новое соединение выкидывает предыдущее. И в разных задачах используется или один или второй подход. S>>Здорово. То есть теперь мы не можем посмотреть одну и ту же камеру с двух компьютеров.
_>Не смотреть камеру, а иметь доступ к интерфейсу управления. Ты вот видел когда-нибудь, чтобы например к одному дрону можно было подключиться с двух контроллеров? Может это тоже недостаток продукта? )))
Запросто — один управляет дроном, другой управляет вспомогательными камерами дрона и другими его устройствами, что на него навешаны.
Здравствуйте, alex_public, Вы писали: _>О, я тут заметил что как-то пропустил твоё старое сообщение (я вообще через уведомления в почте читаю этот форум).
Ну, это типичные издержки RPC-style коммуникации на основе "пересылки оповещений о событиях".
Гораздо надёжнее — REST-подход: https://rsdn.org/Users/Private/MyRsdn.aspx?go=answers
Заходите по этой ссылке, видите список всех ответов на ваши сообщения.
Заботливый браузер (даже если это Links) подсвечивает чёрненьким те из них, которые вы ещё не читали
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Как я и предполагал — там просто балом заправляют криворукие. Весь этот прекрасный gRCP API периодически ложится на полдня.
С этой точки зрения, какие-то мифические микросекунды выигрыша от переезда — фикция.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Shmj, Вы писали:
S>Вот, кстати, что на счет Go?
S>Из коробки компилится под множество платформ. Какие минусы в сравнении с тем же C++?
Изначально язык был создан Гуглом, чтобы снизить порог вхождения по сравнению с С/С++. Хороший компилятор и сильно упрощенные возможности нацеленны на то, чтобы не дать сделать ошибку. Если учитывать, что компиляторы оптимизируют сейчас в большинстве лучше чем человек, а на первый план выходит стоимость и скорость разработки (и сопровождения), то у С/С++ остается не так много козырей: умеечи можно написать производительнее / оптимизированее что-то монструозное или заточенное под железо.
Личное мнение: после С++ слёзы наворачиваются от примитивности, но что делать — такие времена.
80% людей оценивают свое мастерство выше среднего...
Здравствуйте, Няшка, Вы писали:
Н>Здравствуйте, Shmj, Вы писали:
S>>Вот, кстати, что на счет Go?
S>>Из коробки компилится под множество платформ. Какие минусы в сравнении с тем же C++?
Н>Изначально язык был создан Гуглом, чтобы снизить порог вхождения по сравнению с С/С++. Хороший компилятор и сильно упрощенные возможности нацеленны на то, чтобы не дать сделать ошибку. Если учитывать, что компиляторы оптимизируют сейчас в большинстве лучше чем человек, а на первый план выходит стоимость и скорость разработки (и сопровождения), то у С/С++ остается не так много козырей: умеечи можно написать производительнее / оптимизированее что-то монструозное или заточенное под железо. Н>Личное мнение: после С++ слёзы наворачиваются от примитивности, но что делать — такие времена.
Здравствуйте, CreatorCray, Вы писали:
CC>Ага, ага. Это примерно как люди изобрели туалетную бумагу и всякие там биде потому что не хватает опыта/знаний/желания уметь пальцем жопу вытирать.
Сейчас почитателей пакетных менеджеров, которые при установке килобайтной утилиты тащат из инета гигабайты дерьма, причем уже того же, что и установлено, но чуть других версий внимательно осматривают и обнюхивают пальцы.
З.Ы. Так ты Шеридану и отвечаешь , не заметил сразу
Здравствуйте, vaa, Вы писали:
vaa>Здравствуйте, DarkEld3r, Вы писали:
DE>>Здравствуйте, vaa, Вы писали:
vaa>>>это "" пустая строка, довольно странное решение.
DE>>А что должно быть?
vaa>null
:============================== definitely null
80% людей оценивают свое мастерство выше среднего...
Меня всегда изумляли ситуации, когда люди намеренно делают продукт хуже, вместо того, чтобы немножко подумать.
