Adamos, в основе демократии лежит личный выбор, а не оглядки на других. Пассионарий делает так, как считает правильным, независимо от того поможет это или нет, а ведомый находит для себя оправдание, чтобы ничего не делать.
Максим Федоров, предположим, есть всего 3 провайдера. И каждый из них знает, что как только введёт какую-то непопулярную меру, его клиенты уйдут к другому. Даже если они все будут обязаны ввести эту меру, больше всех потеряет тот, кто сделает это первым, а получит больше всех тот, кто сделает последним. В таких условиях провайдеры будут бороться с законами наносящими им вред, оттягивать их выполнение и даже платить штрафы за невыполнение до тех пор, пока убыток от этого будет меньше, чем прибыль от сохранения клиентов. Но по факту провайдеров больше и резать VPN они не обязаны. Делают они это потому, что уверенны в безропотности своих клиентов.
vante_scribaxxi, то есть переложить выполнение долгой задачи на асинхронный сервис, типа Celery, а через Flask только выдавать этому сервису задачи и получать статус выполнения. Естественно, это исключает возможно ставить задачу на паузу, а точнее делает её бессмысленной.
Web-фреймворки, к которым Flask и относится, работают по протоколу http. Протокол http работает в режиме запрос-ответ без состояния. Проще говоря, реализовать продолжительный процесс с интерактивным интерфейсом в таких фреймворках невозможно или очень сложно. Копайте в сторону websocket'ов, но не ожидайте хоть сколько-нибудь приемлемой производительности. А ещё лучше измените логику работы приложения так, чтобы она соответствовала условиям работы в web.
mr_drinkens89, в целом правильно, но не знаю, что у вас под "юзеру летит" подразумевается. Если с юзером не удерживается активное websocket-соединение, то в реалтайме он уведомление не получит. Можно организовать механизм доставки сообщений при следующем обновлении страницы: задача celery при срабатывании создаёт запись в базе с сообщением определённому пользователю, а специальный middleware при следующем запросе этого пользователя добавляет ему flash message в ответ. Ну или взять готовый django-stored-messages.
mr_drinkens89, задания celery хранятся в базе, так что запланированное никуда не денется. Про redis не могу ничего сказать, использовал всегда rabbitmq, а он гарантирует доставку. Единственное, что может пойти не так - сервисы celery не будут запущены в момент наступление времени задачи.
Roger Martino, xml сложнее парсить, xml требует больше ресурсов для парсинга и xml многословнее, а значит отожрёт бо́льшую часть канала передачи данных, чем json.
