Алексей Бердников: Если для вас вебсокет сервер "черный ящик" , то мой вариант вам не подойдет. Я писал свои решения для вебсокет серверов, где мог кастомно обрабатывать любые входящие данные.
Алексей Бердников: ну это вы уже можете преобразовать сообщение в json или другой сериализатор , а на стороне вебсокет сервера вытащить название канала. Т.е. к примеру передать вместо $msg - json_encode(array('msg' => 'hello', 'channel' => 'all'))
Василий Воробьёв: в общем проблема в том, что перед вторым параметром-строкой забыли указать идентификатор "r" , а регулярку поставьте мою, ваша неправильная
Василий Воробьёв: {code}re.sub(r'([:;])(\d+\))', r'\1br\2', p.text, flags=re.UNICODE){code} - так будет работать, второй параметр тоже регулярное выражение
Вячеслав Беляев: вы делаете велосипед, попробуйте вебсокеты, на nodejs или python + tornado. Они разворачиваются за полчаса-час. Если не знаете, то потратите 3-4 часа и получите хорошее решение.
Суть long polling - вы посылаете запрос на сервер и этот запрос там висит без ответа, пока не появится условие , чтобы отдать ответ и закрыть его. Т.е. мы посылаем запрос, а на сервере проверяем (в цикле) есть ли, допустим, новые сообщения для пользователя (в базе), если их нет, то мы делаем sleep() , после выхода из sleep() мы опять проверяем есть ли новые сообщения для пользователя , и если есть, то отдаем, а если нет, то опять засыпаем и проверяем в следующей итерации. Это та реализация лонгполлинга, к которой привык я, возможно вы ее неправильно реализовываете. Т.е. на сервере должна быть итеративная проверка данных для отдачи запросу, сон и условие, которое когда-нибудь выполнится, чтобы запрос закрылся, отдались данные и заново послался запрос на сервер. Если условие проверяется нечасто(допустим раз в 30-60 секунд), то смысл в лонгполлинге остается. Если данные от сервера пользователю должны доставляться чаще или сервер должен сам инициировать отправку данных пользователям - тут больше подходят вебсокеты.
Вячеслав Беляев: неактуальные процессы long polling отключаются по условию, т.е. после каждой итерации сна делайте проверку, которая точно когда-нибудь вернет false и long polling закроется. Ситуацию с несколькими вкладками можно решить записью сессий в быстрые бд вроде redis.
Ну в данном случае видно минусы, что один пользователь создает вам кучу висящих в памяти процессов, что есть очень плохо, если не ограничивать их в этом. Мне кажется, что сокеты решат вашу проблему проще и лаконичней.
slowkazak: во-первых, вы можете удалять так
delete arr[key];
во-вторых, у вас неверно описана переменная (попробуйте в консоль скопипастить)
в третьих, key - это только индекс(строка или число), в вашем случае это будет 0 на первой итерации и 1 на второй
Я не iOS разработчиком работаю, поэтому уже на память не вспомню, но вроде там при инициализации ImagePicker контроллера задается параметром откуда брать фото - из каталога или с камеры. А выбор можно осуществить выводя попап по клику на UIImageView с тремя опциями "Камера, Фото и Отмена". А потом уже при выборе опции инициализировать контроллер с нужным параметром.
qqignatqq: JS не может знать когда закончится ваша анимация CSS , поэтому нужно явно задать таймаут для отработки второго тоггла, т.к. колбэк тоггла отрабатывает сразу после присвоения класса, но когда анимация еще не отыграла.
