норм, нафига тогда писал?

Я не знал, что отойду.

плохо рассматривал

щас бы в 2017ом пользователя руками заставлять что-то апдейтить)

щас бы в 2017ом пользователя руками заставлять что-то апдейтить)

можешь написать это вк)

можешь написать это вк)

а что там руками надо апдейтить?

можешь написать это вк)

ты там руками что-то обновляешь?

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

а что там руками надо апдейтить?

новые новости и комменты, если страница не активна

вот прямо сейчас у меня в ленте уведомление - 95 новых новостей

речь о андроид версии?

*веб-клиент конечно

на дроиде и айос надо потянуть вниз

не знаю. у меня новости на лету обовляются в веб

не знаю. у меня новости на лету обовляются в веб

у меня тоже, но ты страницу не активной оставь и посмотри

вот прямо сейчас у меня в ленте уведомление - 95 новых новостей

мне кажется, это не потому что они не могут, а чтобы лишний раз юзера не нагружать я так бывает вкладку с новостями оставлю, часов через 20 вернусь на нее - а там over9000 новостей новых, и ты прикинь если бы они автоматически загружались

но я сказал выше, акцент не на этом, не важно сами или клиент этим рулит

факт в том, что не реал-тайм, а подписка

Так он же только число новых новостей/комментов отображает, а не все новые новости/комменты

@dmsol тут наверно дело в том, что своей подгрузкой они будут сдвигать страницу вниз. сидишь читаешь пост и херак он уехал

Понеслась

@yegor256 фоткай гугу! он слева от тебя на первом ряду сидит!

Егор

фоткай гугу

@yegor256 если увидишь школьника, который перебегает с места на место - это гуга!

мне кажется @guga4ka выкладывает фото уже после того как поменял место дислокации

Егору кажись совсем делать нечего))

Только Гугу фотать

Надо поднять записи с камер) 100% гуга метаданные фото не тёр)

сверх разум

Надо поднять записи с камер) 100% гуга метаданные фото не тёр)

Что тебе даст? Локацию?

Что тебе даст? Локацию?

Ну, твоё фото, нет?)

Тут человек 200 в комнате

Тут человек 200 в комнате

Ну ты дал 2 фото, так что можно сузить круг)

Сделал фотку и сел в непреметное место

Удачи

?

Сделал фотку и сел в непреметное место

на видео понятно будет, кто фоткал

легко совместить с изображением слайдов Егора

и человека. который пересаживается

Давай

А что в гуге такого секретного?

А что в гуге такого секретного?

Ничегошеньки. Не знаю почему они прислали.

@dmsol, в клиенте есть список всех заказов, в таблице. Каждый клиент (администратор) может нажать на заказ, принять или удалить его. Принятие и удаление происходит только, если заказ еще не принят. В случае, если он принят, клиенту об этом сообщается. Если делать не реалтаймовую подгрузку, очень часто клиент будет попадать в уже принятый заказ, в следствии чего, придется постоянно просить "обновить", что очень неудобно при большом количестве изменений. То, что заказы постоянно летают туда-сюда проблема, но они начинают летать только в видимых пределах таблицы и только при добавлении и удалении. Так же у таблицы будет функция: если пользователь видит самый нижний элемент, то таблица сдвигается вниз при добавлении, а если нет - ничего не сдвигается, просто накапливается внизу. Никто никуда не будет "улетать". При этом выделение не слетает, так что вполне удобно. Цель реалтаймовости в том, чтобы было видно реальное состояние видимых заказов, чтобы не пытаться с ними делать что-то "в холостую", после чего будет отображаться сообщение "обновите таблицу, заказ уже принят".

да нет у тебя реал тайма

тебе сказали уже

это не реалтайм

Почему? Сказать-то сказали, только почему...

Почему? Сказать-то сказали, только почему...

потому что в общемпринятом определении реалтайма лейтенси -- доли секунды а для такси и 10с вполне ок

По следам гуги

потому что в общемпринятом определении реалтайма лейтенси -- доли секунды а для такси и 10с вполне ок

даже до минуты, пожалуй -- тормозить процесс будет человек

потому что в общемпринятом определении реалтайма лейтенси -- доли секунды а для такси и 10с вполне ок

а что (кроме сети) ему мешает укладываться в десяток мс, если все крутится в памяти?

По следам гуги

Oh shi~

а что (кроме сети) ему мешает укладываться в десяток мс, если все крутится в памяти?

а оно надо? use the least powerful tool

а оно надо? use the least powerful tool

а разве вопрос стоит надо или нет?

человек спрашивает: "правильно ли я делаю, если надо"

а вы его убеждаете что не надо

xy problem

@dmsol, в клиенте есть список всех заказов, в таблице. Каждый клиент (администратор) может нажать на заказ, принять или удалить его. Принятие и удаление происходит только, если заказ еще не принят. В случае, если он принят, клиенту об этом сообщается. Если делать не реалтаймовую подгрузку, очень часто клиент будет попадать в уже принятый заказ, в следствии чего, придется постоянно просить "обновить", что очень неудобно при большом количестве изменений. То, что заказы постоянно летают туда-сюда проблема, но они начинают летать только в видимых пределах таблицы и только при добавлении и удалении. Так же у таблицы будет функция: если пользователь видит самый нижний элемент, то таблица сдвигается вниз при добавлении, а если нет - ничего не сдвигается, просто накапливается внизу. Никто никуда не будет "улетать". При этом выделение не слетает, так что вполне удобно. Цель реалтаймовости в том, чтобы было видно реальное состояние видимых заказов, чтобы не пытаться с ними делать что-то "в холостую", после чего будет отображаться сообщение "обновите таблицу, заказ уже принят".

> очень часто клиент будет попадать в уже принятый заказ я в это мало верю

учитывая число клиентов

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

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

очередь фу же xD

почему вы пытаетесь исправить бизнес-требования, чтобы они ложились на ваше решение? конкретно же написано "моментально отображать изменения заказазов в клиентских программах (до 100 машин). "

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

почему вы пытаетесь исправить бизнес-требования, чтобы они ложились на ваше решение? конкретно же написано "моментально отображать изменения заказазов в клиентских программах (до 100 машин). "

потому что я ставлю под сомнения, что @rostislav_dugin адекватно проанализировал требования

ERROR: S client not available

и что реально нужно заказчику

а какая вам разница до его бизнес области, если спрашивают техническое решение?

Берял, тебе попиздить или что-то по делу можешь сказать?

а я по делу говорю

@dmsol, a почему не отправлять сразу изменения? Это и будет мой вариант. С "забрать результат" - просто лишний шаг.

предложи своё

предложи своё

мое мнение в том, что в условиях 1-2гб озу пушить данные в сокеты не такая уж и плохая идея, не хуже очередей так точно

Если честно, заказчик сказал "сделай", чтобы было удобно. И все... А, по скольку деньги платят, я взялся. Так что требования можно корректировать.

@dmsol, a почему не отправлять сразу изменения? Это и будет мой вариант. С "забрать результат" - просто лишний шаг.

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

Если честно, заказчик сказал "сделай", чтобы было удобно. И все... А, по скольку деньги платят, я взялся. Так что требования можно корректировать.

@ppressives ч.т.д.

Пойдем от обратного: чем плох вариант с отправкой потока изменения через сокеты на сразу все клиенты?

@ppressives ч.т.д.

ну если это чат о помощи и анализе требований заказчика и ответа на вопрос, который не задавали, то ты прав. а пока не согласен

как минимум тем, что ему нужно будет реализовать логику для проверки, а не потеряли ли сообщение)

Если я правильно понял устройство NIO, они не забирают на одно соединение поток и могут делать все более-менее параллельно.

Пойдем от обратного: чем плох вариант с отправкой потока изменения через сокеты на сразу все клиенты?

допустим, у тебя оборвалась связь, как данные до клиента дойдут?

как дела с потерями?

ну если это чат о помощи и анализе требований заказчика и ответа на вопрос, который не задавали, то ты прав. а пока не согласен

если ты не согласен, предложи свой вариант решения, конкретно этой задачи

Если я правильно понял устройство NIO, они не забирают на одно соединение поток и могут делать все более-менее параллельно.

эт слишком низкоуровневое решение, возьми хотябы grpc2

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

хотя там тоже с потерями не очень

и попробуй только поправить меня, что требования не корректны

почему вы пытаетесь исправить бизнес-требования, чтобы они ложились на ваше решение? конкретно же написано "моментально отображать изменения заказазов в клиентских программах (до 100 машин). "

потому что для реалтайма все вышеописанное не катит

не совсем корректные исходные данные

"как мне выкопать яму 10х10х10 вилкой"

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

Берял доебался, чтобы доебаться, но не предложил ничего взамен

Берял доебался, чтобы доебаться, но не предложил ничего взамен

сначала добейся?

сначала добейся?

обязательно

потому что для реалтайма все вышеописанное не катит

Почему? Что не так с реалтаймом?

потому что для реалтайма все вышеописанное не катит

очевидно же что не имелся в виду реалтайм, а просто относительно быстрая доставка новых данных

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

нет, у тебя может и клиент и сервер упасть

очевидно же что не имелся в виду реалтайм, а просто относительно быстрая доставка новых данных

Да.