MG
Так это по времени, получается
Size: a a a
2021 January 12
SP
это еще presence detection называют вроде
HH
Так это по времени, получается
Ну с тех. стороны - да. Со стороны бизнеса - нет
MG
Presence detection или activity recognition - это для клиента. Тут же API
SP
Presence detection или activity recognition - это для клиента. Тут же API
а если серверу надо знать что клиент ушел?
HH
atcq (Алексей)
а у вас есть штрафные санкции за удержание лока сверх разумного лимита?
В моем кейсе вообще только один человек получает такую задачу - изменить расписание. Делается нечасто. Это просто защита от дурака
SP
например вот в чатике у тебя надо показывать онлайн ты или оффлайн)
MG
Human Human
Ну с тех. стороны - да. Со стороны бизнеса - нет
Ну у вас же есть правило от бизнеса по которому вы определили цикл таймера? Допустим он 2 минуты. Почему вы просто не установите 2 минутный интервал, который будет сбрасываться спустя этот ttl. Если кто-то стучит кроме авторизированного ранее - получает 409, если стучит спустя 2 минуты - получает доступ. Мне просто непонятно зачем вы наворачиваете столько
MG
а если серверу надо знать что клиент ушел?
Если надо - будет знать. Не понимаю вопроса. Мой поинт - задача совместного доступа решается через ttl-key в кеше и 409 кодом http. Зачем 4 эндпоинта?
SP
Если надо - будет знать. Не понимаю вопроса. Мой поинт - задача совместного доступа решается через ttl-key в кеше и 409 кодом http. Зачем 4 эндпоинта?
что бы обновлять локи)
SP
скажем у тебя "окно" 20 секунд - мол если клиент не сообщал что редактирует в течении 20-ти секунд считать что он ушел и можно разлачивать
SP
или 10 секунд... и ты будешь раз в 5 секунд автоматом слать запросы что "я еще тут я еще не ушел"
SP
у меня например есть кейсы когда мне надо трекать "когда ушел". Потому что от этого биллинг строится)
MG
Я ничего не буду слать. Есть API которое позволяет редактировать что-либо. Для API нужно гарантирвоать неконфликтность изменений. Кто первый пришёл с запросом на изменение - тот и поменял. Если он пришёл в течении двух минут - окно за ним. Если после и кто-то в это время внёс свои правки - окно за другим. В чём проблема и почему так не сделать?
HH
Ну вот у меня для этого эндпоинты и есть
/schedule/start-editing - захват лока
/schedule/continue-editing - пинг, что еще редактируем
/schedule/change - изменяем и отпускаем лок
/schedule/no-change - не изменяем и отпускаем лок
/schedule/start-editing - захват лока
/schedule/continue-editing - пинг, что еще редактируем
/schedule/change - изменяем и отпускаем лок
/schedule/no-change - не изменяем и отпускаем лок
HH
Ну у вас же есть правило от бизнеса по которому вы определили цикл таймера? Допустим он 2 минуты. Почему вы просто не установите 2 минутный интервал, который будет сбрасываться спустя этот ttl. Если кто-то стучит кроме авторизированного ранее - получает 409, если стучит спустя 2 минуты - получает доступ. Мне просто непонятно зачем вы наворачиваете столько
Что тут хочешь скоратить?
HH
Я ничего не буду слать. Есть API которое позволяет редактировать что-либо. Для API нужно гарантирвоать неконфликтность изменений. Кто первый пришёл с запросом на изменение - тот и поменял. Если он пришёл в течении двух минут - окно за ним. Если после и кто-то в это время внёс свои правки - окно за другим. В чём проблема и почему так не сделать?
А понял, ну у меня просто другой кейс
HH
Мне так не нужно)
MG
Можно сделать
PUT /schedule/schedule
и решить вопрос, нет?
PUT /schedule/schedule
и решить вопрос, нет?
SP
Я ничего не буду слать. Есть API которое позволяет редактировать что-либо. Для API нужно гарантирвоать неконфликтность изменений. Кто первый пришёл с запросом на изменение - тот и поменял. Если он пришёл в течении двух минут - окно за ним. Если после и кто-то в это время внёс свои правки - окно за другим. В чём проблема и почему так не сделать?
если у тебя есть требования "что бы не перетерли" и высокие риски что перетрут (бронирование тоже)