Форум PHP

ну, типа того ))
но наш микроскоп весьма удобен, прост в использовании и потребляет всего несколько ватт электроэнергии. С лупой примерно тоже самое, только возможностей у неё меньше, но в принципе, и этих возможностей здесь достаточно.

А на деле решение может оказаться весьма удобным.
Псюс ко всему - это возможность пощупать на практике возможности HTML5.

> Но подобного рода рояли в кустах как минимум должны быть описаны в
> соглашении о конфиденциальности.
Это уже другой вопрос :)

пока оно в кукисах - это мусор.
А на сервере оно - повод накатить иск о неправомерной обработке персональных данных :)

Не то что бы это вообще нельзя делать.
Но подобного рода рояли в кустах как минимум должны быть описаны в соглашении о конфиденциальности.

заноза в пальце.
Если есть микроскоп, лучше электронный - используем его.
Если нет - обходимся увеличительным стеклом.
:))

Как вариант можете использовать для этих целей локальное хранилищие.
Алгоритм может быть следующий: после получения браузером страницы с товаром, удаляете из хранилища все товары, которые находятся в хранилище более суток, далее, с помощью AJAX получаете от сервера данные всех товаров, которые находятся в хранилище и добавляете их на страницу (можно, конечно, вообще всё хранить в хранилище и AJAX-запросы не отправлять, но тогда есть риск рассинхронизации с сервером - допустим товар вы из базы удалили, а в хранилище он осталься и пользователь его увидит ).
Ну и после этого проверьте сохранён ли текущий товар в хранилищи или нет. Если сохранён, то ничего делать не нужно, если нет - добавляете его туда.

Минус этого подхода заключается в том, что он, в чистом виде, работать с IE7 и IE6 не будет (т.к. эти браузеры не поддреживают работу с локальным хранилищем). Но, в принципе, это ограничение легко обойти: вначале проверить доступно ли хранилище, если да - используем его, если нет - используем куки. Или же можно вообще эту рутину переложить на плечи плагина jStorage.

>я же саму куку храню сутки. вот за сутки и пусть накапливаются.
да. Но из вчера установленной куки (которая сегодня еще читается, а завтра уже не должна) попадут товары в куку сегодня установленную (которая еще будет читаться завтра)
Так что метки придется все же держать.
И здесь проблема в том, что метки времени более громоздкие, чем сами ключи.
Если бы можно было ослабить ограничение суточного хранения, например, так:

пользователю видны товары, которые он смотрел в пределах 1-2 суток,

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

Вы забудете, а маркетологи нет. Тем более про базу данных я сказал "например".

В куках не может храниться большое количество информации. Говорят не более 64 КБ. А если пользователь настолько активен, что за сутки превысит этот предел?

завтра я про этого клиента и думать забуду.

Сейчас это мусор, а завтра нет.