Sergey Fedorov: вы не давайте заднюю - я утвержал, что ваше решение в корне неверно т.к. вы используете куки не для того, для чего они предназначены. не мне решать верное мое решение или нет. пока я подвергаю критике ваше предложение
Sergey Fedorov: куки вообще-то используются для хранения данных. то, что у некоторых получается забить головой гвоздь еще не значит, что это правильное решение.
ваше решение с куками родилось в виде "о, куки есть и на сервере и на кленте, можем записать в на кленте и прочесть на сервере. круто! а может не успеть записаться - добавим таймаут. да, должно работать"
я, к примеру, не знаю правильного решения вопроса чтобы покрыть все возможные варианты поведения пользователя, включая открытие ссылки в новой вкладке/окне браузера. правильно было бы как-то маркировать ссылки в менюшке, добавляя параметр
ну ок, вы считаете, что решение с куками является верным - я не буду доказывать вам обратное
Sergey Fedorov: для хранения некоторых (мета)данных на стороне клиента с сохранением их между сессиями (открыл-закрыл вкладку/браузер). все то, что вы скопировали с википедии является следствием. вы же предлагаете с помощью кук неявно передавать информацию с клиента на сервер. это запутывает код и понимание процесса работы сервиса
LordGuard: вот так уже лучше. тогда делайте в контроллере редирект на очищенную ссылку Sergey Fedorov вариант с кукой в корне неправильный. это называется закостыливание - вы используете механизм кук не для того, для чего он предназначен
LordGuard: что есть "чистая" ссылка и для кого она важна? если для SEO, то она будет "чисто" - без лишних параметров. если это важно для контроллера, то она не будет "чистой" - там будут дополнительные параметры
вы бы описали более конкретно что вы имеете (фреймворк, CMS, самописную на коленке лобуду), ограничения (что за "чистая ссылка", для чего это) и чего вы хотите добиться. так было бы намного проще
Mike Evstropov: да, но оно работает. еще как вариант можете добавить к каждому корню дерева какой-то сортировочный столбик, но тогда придется его добавлять ко всем его узлам и листьям. и это будет неправильным
вообще архитектурно нелогично то, что Вы хотите хранить в одной таблице два дерева и при этом выводить их корни отсортировано. если вы их хотите выводить отсортировано, то предполагается то, что это сущности из одного семейства и, следовательно, они должны храниться в одном дереве
действительно, два дерева нельзя отсортировать относительно друг друга. это просто нелогично т.к. это предполагается, что это два разных дерева и два разных семейства сущностей
Alexander K.: плотно с socket.io я не работал. я работал с нативной реализацией веб-сокетов в ноде. вот что я имею в виду
вы запускаете веб-сокет сервер. когда кто-то коннектится к веб-сокет серверу вы можете получить соединение. некий объект, который инкапсулирует соединение с клиентом. вы можете отправить что-то на это соединение - оповестить клиента. вы можете завести сторедж, в котором храните все соединения, такой себе массив. когда кто-то подключается к серверу - вы кладете в этот массив объект-соединение. когда кто-то отключается - вы удаляете из него это соединение.
теперь берем RabbitMQ. это такой себе сервер очередей, который принимает сообщения на одном конце и отдает из на другом конце. там много всего интересного, но нам все не нужно. нам важно то, что он слушает одним концом и говорит другим концом. итак, вы запускаете веб-сокет сервер, он работает, принимает соединения и дополнительно слушает RabbitMQ сервер. если он что-то от него получает (там тоже на событиях завязано), то он что-то делает. запомним этот момент.
с другой стороны у вас есть крон-джоба, которая когда-то там запускается. неважно когда, важно, что она запускается. при запуске этой джобы вы можете обратиться к RabbitMQ серверу и сказать ему что-то (он слушает), он примет это и передасть это дело на веб-сокет сервер, который слушает этот же RabbitMQ сервер.
возвращаемся к веб-сокет серверу: он что-то услышал от RabbitMQ сервера (например, нужно что-то броадкастить на все соединения), он берет данные, которые узнал от RabbitMQ сервера, берет все соединения из стореджа (помните тот массив, в который мы складировали соединения?) и отправляет это каждому соединению.
приблизительно так я предлагаю Вам сделать. в socket.io есть broadcast на все активные соединения и потому, возможно, не нужно складировать в отдельный сторедж, но это не суть. вам нужно как-то связать крон-джобу с работающим веб-сервером. я предлагаю вам использовать RabbitMQ сервер. можно обойтись и без него, выделив для этого отдельный канал в socket.io сервере, коннектиться к нему из крон-джобы и отправлять на него свое сообщение. может еще можно повесить аунтентификацию на этот канал (я не помню уже как там с этим в socket.io). так будет даже безопаснее
под своп "стандартно" - это один к одному с оперативой (4Гб оперативы - 4Гб свопа)
зачем х2 в своп? вопрос нериторический - мне действительно интересна причина
kpa6uu: просто так прозрачно со старта этого не сделать. разве что через `eval`, но это зло. красивее всего было бы написать объектную обертку для работы с таким массивом с методами get, set, change и так далее. Вы определитесь что Вам нужно и изложите это нормально
Sanes: простите за нескромный вопрос: Вы тупой? я мысли не читаю и мои телепаты в отпустке. я задал конкретный вопрос. если Вы не можете нормально развернуто и с примером на него ответить или Вы считаете недостойным отвечать на подобные вопросы, то лучше вообще ничего не отвечать
