Хорошая статья, спасибо.
Я слыхал о скрипте PersistJS (http://pablotron.org/?cid=1557 или тут по-русски http://www.jstoolbox.com/2008/05/22/persistjs-sessii-v-javascript-bez-cookies/) - он автоматически определяет, какой способ доступен, globalstorage либо userdata, либо что-то еще. Если вообще ничего не доступно, то флэш используется.
Уж очень не удобно в реальности работать с этим. Все же проще будет хранить данные превыщающие 2 кб на сервере в базе, а в куках хранить их идетификатор.
Смотря для каких целей, к примеру этим способом можно делать авто сохранение текста набранного пользователем, не обращаясь каждый раз к серверу и не тратя попусту пользовательский трафик, либо банить нарушителей. Чистку кукисов, смену айпишника, заход через прокси умеют многие, а почистить такое будет трудновато
Так я же говорил про кросс браузерность, тоесть флеш был бы мостом между браузерами, конешно не спорю што обойти можно все, но такой подход пока што новый, поэтому пока пользователи догадаются контролировать порядок можно
хороший способ. только далеко не всегда пользователь должени видеть подобного рода информацию.
ИМХО проще создать сессию и хранить неограниченное количество информации на сервере.
1. Использование локального хранилища позволяет организовать обмен данным между окнами браузера (причём не важно, как эти окна были открыты и что с ними происходило)
2. Можно сохранять данные пользователя даже в offline
> но ограничение хранения данных в размере не более 2kb не всех радует, сегодня если позволите я вам расскажу как посредством Java Script хранить около 100kb на клиенте.
Во-первых, ограничение не 2Kb, а 4Kb на куку. Во-вторых, на одном домене можно одновременно иметь до 20 кук включительно. Итого, суммарно, можно, используя механизм Cookies, оперировать 80Kb. А еще можно сжимать данные, таким образом хранить больший объем данных в этих доступных 80Kb.
Но в любом случае я согласен, что большие объемы данных в куках держать глупо, так как все эти данные будут отправляться на сервер при каждом реквесте.
For one domain name, each cookie is limited to 4,096 bytes. This total can exist as one name-value pair of 4 kilobytes (KB) or as up to 20 name-value pairs that total 4 KB.
Спасибо за ссылку, признаю свою неправоту. Спека, которой я пользовался, http://www.w3.org/Protocols/rfc2109/rfc2… (пункт 6.3) не говорит об этом прямо, и лишь дополнительная информация по приведенной Вами ссылке проясняет этот момент.
А вот насчет последнего я не уверен. Как тогда это понимать (из того же пункта 6.3, кстати это цитируется в приведенной Вами ссылке): "at least 20 cookies per unique host or domain name"? Как раз это и сбивает с толку, и вносит путаницу что они называют термином cookie - то ли одну пару ключ-значение, то ли "всю сессионную информацию"?
Забавно. Только что поставил эксперимент, использовал 3 браузера - IE7, FF2 и Opera 9.27. Результаты, мягко скажем, неожиданные, и отличается от того, что в спецификации:
1. IE и FF позволяют работать с 50 куками (парами ключ-значение).
2. Opara позволяет работать только с 30 куками.
3. Все три браузера принимают куки, суммарный размер которых больше чем 4 килобайта (как раз максимум по 4 килобайта на каждую, как в спеке), и сохраняет их на диске в полном объеме.
4. Opera, когда посылает респонс, отправляет куки серверу только пока суммарный их размер не превышает 4 килобайта. Если суммарный размер кук больше, то отправляются только первые из них, суммарный размер которых в пределах 4 килобайт.
5. IE и FF пытаются отправить серверу все куки что есть, игнорируя размеры. При этом сервер (в моем случае Apache 1.3) ругается на неправильный заголовок, мол, превышен размер.
Итак, вывод из этой лабораторной работы. Спека - это одно, а на практике оказывается, как обычно, производители браузеров ей не очень следуют.
Если хранить данные клиента в базе данных, то в принципе можно с ними работать через Request.
То есть создать методы (сервер-сайд)
сreateCookie()
setCookieData($keyName,$value)
getCookieData()
removeCookie()
сreateCookie() - создает запись в таблице и возвращает уникальный ид который мы и будем хранить в обычной куке.
дальше посредством setCookieData($keyName,$value) сохраняем данные в таблице и посредством getCookieData() достаём массив данных.
Когда нам это всё больше не нужно, вызываем removeCookie() который стирает запись из таблицы.
Естественно надо продумать механизм безовастности.
Я просто предлагаю хранить данные на клиенте посредством браузеров, а для кросс браузерности использовать мост через Local SharedObject от флеша поддерживаемым всеми браузерами где установлен флеш, это позволит синхронизировать данные между всеми браузерами и с большей мощью использовать хранилище. Мне тут еще подсказали что помимо флеша, такой мост можно организовать посредством Google Gears либо Adobe Air, о чем я забыл упомянуть в своей статье.
Вот, теперь сайтам нужно полноценное хранилище данный на клиенте.
Всё больше нужны нормальные инструменты создания интерфейсов (окон и проч.), кроссбраузерно и по стандарту.
Будущее веба в изолированных веб-приложениях?
И хранилище, и отрисовка окон и прочих элементов, и ещё что-нибудь?
Очень мне хочется, чтоб вэб интерфейсы перешли вот в такие изолированные веб-приложения.
ну, статические сайты уже стали прошлым веком, разработчики сейчас пытаются как можно больше в страницы донести динамики и UI. И я думаю чем меньше клиент обращается к серверу, но в ту же очередь в полную мощь использует веб-приложение и динамику тем лутше.
возможно не совсем по теме, но в флеше существует какая то бага при работе с сессиями, в альтернативных експлореру браузерах. По непонятных мне причинам флеш по умолчанию запрашивает кукиз из папки експлорера.
Тут описан пример: http://swfupload.org/forum/generaldiscus…
Альтернатива cookies посредством Java Script