Alexvrs

По большому счету вся дискуссия сводится к этому моменту. Реализация тут особого значения не имеет. Даже если рассмотреть момент, что лежит в кеше уже генерированный файл, этот файл будет достаточно объемным. При старте ваше приложение будет "задумываться" на ощутимо продолжительное время. не совсем так, подгрузка (обновление) ЕПГ организовывается в другом потоке (новейшие модели обладают 2-х ядерными процессорами) и/или по таймеру в ночное время 1. ИМХО ограничение такое будет не уместным, например в случае если произошел сбой и пользователь вынужден перегрузить ПО, очистив кешь и ему необходимо обновить ЕПГ! 2. для ошибок программистов есть более эффективный метод, который применяется ведущими мировыми компаниями (у них есть чему поучиться) - необходимо ввести в API понятие персональный индентификатор разработчика (например такой есть у Last.FM, google и т.д.) этот индентификатор выдается каждому разработчику и регламинтируется лицензионным соглашением, а также в случае не корректной работы приложения у вас появляется персональная обратная связь (e-mail) и однозначная индентификация этого разработчика + появляется цевилизованный механизм блокировки доступа приложения избранного разработчика, в случае возникновения нештатной ситуации до решения проблеммы (и/или выдача разработчику нового индентификатора, если необходимо отсечь не обновленное не корректно работающее ПО)

С возвращением Тут с Вами не соглашусь: 1. Интересует выдача не на ОДИН день а сразу на все каналы на все дни одним файлом, и ваши доводы мне кажутся не убедительными - это основано на предположении, что ЕПГ вы храните в какой либо БД? 2. Если предположение верно или близко к верному, то о каких ресурсах мы ведем речь, ведь сформировать из БД файл размером 15 мег, занимает 1-2 секунды (и даже если и 1-2 минуты), это конечно в рамках тысяч запросов много, но они не требуются, так как ЕПГ обновляется гораздо реже, гипотетически раз в сутки, и потратить такое время для формирования одного общего файла для всех не проблема для любого сервера (это все равно что сделать бакап БД, что думаю вы регулярно исполняете) 3. Теперь вернемся к вопросу учета таймзоны, в указанном выше варианте даже если генерировать 24 файла для каждой таймзоны, то раз в сутки с точки зрения нагрузки это так же не о чем (объяснения выше) но если это для вашего сервера промышленного маштаба уже напряжно, то и не надо, так как приставки сами в состоянии скорректировать тайм зону (если об этом будут знать разработчики ) 4. Учитывая вышесказанное этот файл забираться будет приставками 1 раз в сутки, что наоборот снизит а не повысит нагрузку на ваш сервер API, а командой к считыванию (при обновлении ЕПГ) будет служить флаг передаваемый в списке каналов и при авторизации 5. Если выдача такого файла опять напряжна для промышленных маштабов серверов API, то этот файл без проблем можно перенести на сервера отдающие стреам поток, а сервер API при этом будет делать простой редирект без дополнительной нагрузки. Надеюсь, что такая промышленная нагрузка будет каплей в море для стреам серверов имеющих зеркала. 6. И наконец для компании извлекающей прибыль будет не лишне для этих целей даже поставить отдельный сервер 7. То как у Вас задумывалось использование API мне прекрасно понятно, но это было "давно" когда Ваш сервис только начинал свое развитие, но ВРЕМЯ идет и теперь вашим сервисом пользуются люди при помощи многофункциональных спутниковых ресиверов на которых ЕПГ выдается не порциями а мгновенно (предварительно кешированное из потока со спутника) и у нас есть возможность предоставить им аналогичный сервис к которому они привыкли!!!! Разве это не повышает конкурентно способность Вашего сервиса? Разьве я не прав? Или все же аксиома "Поэтому - грузим столько сколько надо." и ожидаем каждого запроса от перегруженных серверов API? Думаю для начала дискуссии доводов достаточно, теперь Ваш ход

@mariman В основном много считываний приходится для получения EPG, этому так же способствует функция epg_next, для того чтобы избавится от всех этих запросов, нужно использовать выдачу всего EPG одним запросом (файлом) с указанием даты актуальности, до наступления которой повторного обновления EPG не требуется!!! (при этом можно кешировать этот ответ со стороны сервера). При этом разработчики клиентов просмотра КартинаТВ смогут делать локальный кешь для всей информации и кол-во запросов сведется к нулю!!!, информацию о необходимости обновить EPG (новой или измененной дате) можно также передавать в остальных запросах, например при авторизации. В таком варианте использование API сведется к следующему кол-ву запросов: 1. Авторизация и сравнение даты актуальности информации (можно некий UUID) 2. В случае обнаружения актуальности информации все данные берутся из локального кеша, включая список каналов 3. В случае обнаружения НЕ актуальности информации, сначала можно получить список каналов с текущими передачами для возможности быстрого использования списком текущих передач, а затем загрузить уже целиком EPG в кешь P'S' Неправдали здорова? Всего 1-2 запроса (кешированных на сервере) для каждого пользователя в сутки? P'P'S' все остальные запросы хороши для использования клиентов аля браузер: дал запрос -> ПОДОЖДАЛ ОТВЕТА N СЕКУНД -> вывел результат -> дал новый запрос -> ПОДОЖДАЛ ОТВЕТА N СЕКУНД (это раздражает активных пользователей желающих пощелкать каналы и нагружает излишне сервер)