История изменений
Исправление user_id_68054, (текущая версия) :
Проблема потери событий решается через set-cookie и удаление событий когда от клиента придет новый POST с установленной кукой.
ну можно и так. :)
в этом случае — реализация слегка упрощается на клиенте, и слегка усложняется на сервере (уникальный идентификатор для каждого из состояний — теперь должен отслеживаться на сервере. а в моей схеме — сервер не должен отслеживать уникальные идентификаторы состояния).
по эффективности — примерно тоже самое (чуть-чуть экономнее) — то есть: необходимо 2 запроса на каждую операцию уведомления «server->client» (ведь в случае с cookie сервер не может считать что передача «server->client» прошла успешно до тех пор пока client не пришлёт верный cookie в следующем запросе. то есть за 1 запрос передача «server->client» не произойдёт с точки зрения server, ведь доказательства успешности придут только в следующем запросе от клиента).
впрочем ценой такого усложнения — появляется кой-какая маленькая экономия.. (не могу это не отметить :))
------------------
при этом (в схеме с cookie) мне стоит надеется что web-браузер корректно (атомарно?) обрабатывает ситуацию — когда server успел прислать cookie о НЕ успел прислать body всего ответа (случился разрыв).. в этом случае web-браузер должен НЕ-применять cookie, а он точно это сделает?
Исправление user_id_68054, :
Проблема потери событий решается через set-cookie и удаление событий когда от клиента придет новый POST с установленной кукой.
ну можно и так. :)
в этом случае — реализация слегка упрощается на клиенте, и слегка усложняется на сервере (уникальный идентификатор для каждого из состояний — теперь должен отслеживаться на сервере. а в моей схеме — сервер не должен отслеживать уникальные идентификаторы состояния).
по эффективности — примерно тоже самое (чуть-чуть экономнее) — то есть: необходимо 2 запроса на каждую операцию уведомления «server->client» (ведь в случае с cookie сервер не может считать что передача «server->client» прошла успешно до тех пор пока client не пришлёт верный cookie в следующем запросе. то есть за 1 запрос передача «server->client» не произойдёт с точки зрения server, ведь доказательства успешности придут только в следующем запросе от клиента).
впрочем ценой такого усложнения — появляется кой-какая маленькая экономия.. (не могу это не отметить :))
------------------
при этом (в схеме с cookie) мне стоит надеется что web-браузер корректно (атомарно?) обрабатывает ситуацию — когда server успел прислать cookie о НЕ успел прислать body всего ответа (случился разрыв).. в этом случае web-браузер должен откинуть cookie, а он точно это сделает?
Исправление user_id_68054, :
Проблема потери событий решается через set-cookie и удаление событий когда от клиента придет новый POST с установленной кукой.
ну можно и так. :)
в этом случае — реализация слегка упрощается на клиенте, и слегка усложняется на сервере (уникальный идентификатор для каждого из состояний — теперь должен отслеживаться на сервере. а в моей схеме — сервер не должен отслеживать уникальные идентификаторы состояния).
по эффективности — примерно тоже самое (чуть-чуть экономнее) — то есть: необходимо 2 запроса на каждую операцию уведомления «server->client» (ведь в случае с cookie сервер не может считать что передача «server->client» прошла успешно до тех пор пока client не пришлёт верный cookie в следующем запросе. то есть за 1 запрос передача «server->client» не произойдёт с точки зрения server, ведь доказательства успешности придут только в следующем запросе от клиента).
впрочем ценой такого усложнения — появляется кой-какая маленькая экономия.. (не могу это не отметить :))
------------------
при этом (в схеме с cookie) мне стоит надеется что web-браузер корректно (атомарно?) обрабатывает ситуацию — когда server успел прислать cookie о НЕ успел прислать body всего ответа (случился разрыв)..
Исправление user_id_68054, :
Проблема потери событий решается через set-cookie и удаление событий когда от клиента придет новый POST с установленной кукой.
ну можно и так. :)
в этом случае — реализация слегка упрощается на клиенте, и слегка усложняется на сервере (уникальный идентификатор для каждого из состояний — теперь должен отслеживаться на сервере. а в моей схеме — сервер не должен отслеживать уникальные идентификаторы состояния).
по эффективности — примерно тоже самое (чуть-чуть экономнее) — то есть: необходимо 2 запроса на каждую операцию уведомления «server->client» (ведь в случае с cookie сервер не может считать что передача «server->client» прошла успешно до тех пор пока client не пришлёт верный cookie в следующем запросе. то есть за 1 запрос передача «server->client» не произойдёт с точки зрения server, ведь доказательства успешности придут только в следующем запросе от клиента).
впрочем ценой такого усложнения — появляется кой-какая маленькая экономия.. (не могу это не отметить :))
при этом (в схере с cookie) мне стоит надеется что web-браузер корректно (атомарно?) обрабатывает ситуацию — когда server успел прислать cookie о НЕ успел прислать body всего ответа (случился разрыв)..
Исправление user_id_68054, :
Проблема потери событий решается через set-cookie и удаление событий когда от клиента придет новый POST с установленной кукой.
ну можно и так. :)
в этом случае — реализация слегка упрощается на клиенте, и слегка усложняется на сервере (уникальный идентификатор для каждого из состояний — теперь должен отслеживаться на сервере. а в моей схеме — сервер не должен отслеживать уникальные идентификаторы состояния).
по эффективности — примерно тоже самое (чуть-чуть экономнее) — то есть: необходимо 2 запроса на каждую операцию уведомления «server->client» (ведь в случае с cookie сервер не может считать что передача «server->client» прошла успешно до тех пор пока client не пришлёт верный cookie в следующем запросе. то есть за 1 запрос передача «server->client» не произойдёт с точки зрения server, ведь доказательства успешности придут только в следующем запросе от клиента).
впрочем ценой такого усложнения — появляется кой-какая маленькая экономия.. (не могу это не отметить :))
Исправление user_id_68054, :
Проблема потери событий решается через set-cookie и удаление событий когда от клиента придет новый POST с установленной кукой.
ну можно и так. :)
в этом случае — реализация слегка упрощается на клиенте, и слегка усложняется на сервере (уникальный идентификатор для каждого из состояний — теперь должен отслеживаться на сервере. а в моей схеме — сервер не должен отслеживать уникальные идентификаторы состояния).
по эффективности — примерно тоже самое (чуть-чуть экономнее) — то есть: необходимо 2 запроса на каждую операцию уведомления «server->client» (ведь в случае с cookie сервер не может считать что передача «server->client» прошла успешно до тех пор пока client не пришлёт верный cookie в следующем запросе. то есть за 1 запрос передача «server->client» не произойдёт с точки зрения server, ведь доказательства успешности придут только в следующем запросе от клиента).
впрочем ценой усложнения — появляется кой-какая маленькая экономия.. (не могу это не отметить :))
Исправление user_id_68054, :
Проблема потери событий решается через set-cookie и удаление событий когда от клиента придет новый POST с установленной кукой.
ну можно и так. :)
в этом случае — реализация слегка упрощается на клиенте, и слегка усложняется на сервере (уникальный идентификатор для каждого из состояний — теперь должен отслеживаться на сервере. а в моей схеме — сервер не должен отслеживать уникальные идентификаторы состояния).
по эффективности — примерно тоже самое (чуть-чуть экономнее) — то есть: необходимо 2 запроса на каждую операцию уведомления «server->client» (ведь в случае с cookie сервер не может считать что передача «server->client» прошла успешно до тех пор пока client не пришлёт верный cookie в следующем запросе. то есть за 1 запрос передача «server->client» не произойдёт с точки зрения server).
впрочем ценой усложнения — появляется кой-какая маленькая экономия.. (не могу это не отметить :))
Исправление user_id_68054, :
Проблема потери событий решается через set-cookie и удаление событий когда от клиента придет новый POST с установленной кукой.
ну можно и так. :)
в этом случае — реализация слегка упрощается на клиенте, и слегка усложняется на сервере (уникальный идентификатор для каждого из состояний — теперь должен отслеживаться на сервере. а в моей схеме — сервер не должен отслеживать уникальные идентификаторы состояния).
по эффективности — примерно тоже самое (чуть-чуть экономнее) — то есть: необходимо 2 запроса на каждую операцию уведомления «server->client» (ведь в случае с cookie сервер не может считать что передача «server->client» прошла успешно до тех пор пока client не пришлёт верный cookie в следующем запросе. то есть за 1 запрос передача «server->client» не произойдёт с точки зрения server).
впрочем ценой усложнения — появляется кой какая экономия.. (не могу это не отметить :))
Исправление user_id_68054, :
Проблема потери событий решается через set-cookie и удаление событий когда от клиента придет новый POST с установленной кукой.
ну можно и так. :)
в этом случае — реализация слегка упрощается на клиенте, и слегка усложняется на сервере (уникальный идентификатор для каждого из состояний — теперь должен отслеживаться на сервере. а в моей схеме — сервер не должен отслеживать уникальные идентификаторы состояния).
по эффективности — примерно тоже самое (чуть-чуть экономнее) — то есть: необходимо 2 запроса на каждую операцию уведомления «server->client» (ведь в случае с cookie сервер не может считать что передача «server->client» прошла успешно до тех пор пока client не пришлёт верный cookie в следующем запросе. то есть за 1 запрос передача server->client не произойдёт с точки зрения server).
впрочем ценой усложнения — появляется кой какая экономия.. (не могу это не отметить :))
Исправление user_id_68054, :
Проблема потери событий решается через set-cookie и удаление событий когда от клиента придет новый POST с установленной кукой.
ну можно и так. :)
в этом случае — реализация слегка упрощается на клиенте, и слегка усложняется на сервере (уникальный идентификатор для каждого из состояний — теперь должен отслеживаться на сервере. а в моей схеме — сервер не должен отслеживать уникальные идентификаторы состояния).
по эффективности — примерно тоже самое — то есть: необходимо 2 запроса на каждую операцию уведомления «server->client» (ведь в случае с cookie сервер не может считать что передача «server->client» прошла успешно до тех пор пока client не пришлёт верный cookie в следующем запросе. то есть за 1 запрос передача server->client не произойдёт с точки зрения server).
впрочем ценой усложнения — появляется кой какая экономия.. (не могу это не отметить :))
Исправление user_id_68054, :
Проблема потери событий решается через set-cookie и удаление событий когда от клиента придет новый POST с установленной кукой.
ну можно и так. :)
в этом случае — реализация слегка упрощается на клиенте, и слегка усложняется на сервере (уникальный идентификатор для каждого из состояний — теперь должен отслеживаться на сервере. а в моей схеме — сервер не должен отслеживать уникальные идентификаторы состояния).
по эффективности — примерно тоже самое — то есть: необходимо 2 запроса на каждую операцию уведомления «server->client» (ведь в случае с cookie сервер не может считать что передача «server->client» прошла успешно до тех пор пока client не пришлёт верный cookie в следующем запросе. то есть за 1 запрос передача server->client не произойдёт с точки зрения server).
Исправление user_id_68054, :
Проблема потери событий решается через set-cookie и удаление событий когда от клиента придет новый POST с установленной кукой.
ну можно и так. :)
в этом случае — реализация слегка упрощается на клиенте, и слегка усложняется на сервере (уникальный идентификатор для каждого из состояний — теперь должен отслеживаться на сервере. а в моей схеме — сервер не должен отслеживать уникальные идентификаторы состояния).
по эффективности — примерно тоже самое — то есть: необходимо 2 запроса на каждую операцию уведомления «server->client» (ведь в случае с cookie сервер не может считать что передача «server->client» прошла успешно до тех пор пока client не пришлёт верный cookie. то есть за 1 запрос передача server->client не произойдёт с точки зрения server).
Исправление user_id_68054, :
Проблема потери событий решается через set-cookie и удаление событий когда от клиента придет новый POST с установленной кукой.
ну можно и так. :)
в этом случае — реализация слегка упрощается на клиенте, и слегка усложняется на сервере (уникальный идентификатор для каждого из состояний — теперь должен отслеживаться на сервере).
по эффективности — примерно тоже самое — то есть: необходимо 2 запроса на каждую операцию уведомления «server->client» (ведь в случае с cookie сервер не может считать что передача «server->client» прошла успешно до тех пор пока client не пришлёт верный cookie. то есть за 1 запрос передача server->client не произойдёт с точки зрения server).
Исходная версия user_id_68054, :
Проблема потери событий решается через set-cookie и удаление событий когда от клиента придет новый POST с установленной кукой.
ну можно и так. :)
в этом случае — реализация слегка упрощается на клиенте, и слегка усложняется на сервере (уникальный идентификатор для каждого из состояний — теперь должен отслеживаться на сервере).
по эффективности — примерно тоже самое — то есть: необходимо 2 запроса на каждую операцию оведомления server->client (ведь в случае с cookie сервер не может считать что передача server->client прошла успешно до тех пор пока client не пришлёт верный cookie. то есть за 1 запрос передача server->client не произойдёт с точки зрения server).