Насколько велик XML-файл RSS-канала?

Я реализую RSS-канал для веб-сайта, и я не понимаю некоторых вещей о формате / размере / содержании XML-файла для канала.

Я инициализирую сайт с прошлыми данными, которые относятся к 1999 году (до сих пор никакой ленты не было), и в год будет добавляться только пара сотен элементов.

Есть ли какой-то протокол для архивирования, или я могу просто сохранить один файл и продолжать добавлять к нему? Я думаю, что это было бы неэффективно, поскольку агрегаторы должны загружать все это (я полагаю).

Итак, каков обычный обычай для этого? Ограничить это последним месяцем? Текущий файл с более чем 900 элементами имеет размер 1,5 МБ, и я ожидаю, что размер одного года будет примерно в 10 раз меньше или меньше.

Есть какие-нибудь указания по этому поводу, какие принципы использовать и как это реализовать? Я использую PHP, но мои данные достаточно сложны. Я свернул собственный сценарий, чтобы записать файл (и он отлично себя проверяет), поэтому я не могу использовать готовое решение - мне нужно понять, что реализовать в моем собственном сценарий.


person David-W-Fenton    schedule 15.03.2011    source источник
comment
Какую магию вы применили, чтобы получить ответ? Это было бы намного полезнее для меня 3 месяца назад!   -  person David-W-Fenton    schedule 09.06.2011
comment
Раньше я был фанатом синдикации, и вопрос был скорее архитектурным, чем техническим. Единственное, о чем я не упомянул, это обязательно запускайте свои финальные каналы через validator.w3.org/feed это избавит вас и ваших потребителей от многих страданий!   -  person Oppositional    schedule 09.06.2011
comment
@david я немного отредактировал вашу грамматику, чтобы не обидеть пользователей, и когда вы редактируете вопрос, вопрос получает более высокий рейтинг и большую видимость   -  person Alex Gordon    schedule 10.06.2011
comment
Что ж, я не согласен с вашими изменениями тегов - мой вопрос не о PHP или сценариях. Мой вопрос полностью касается формата вывода RSS. Но я оставлю это в покое, так как я получил ответ, который мне был нужен (всего на 90 дней позже, чем мне это было нужно).   -  person David-W-Fenton    schedule 13.06.2011
comment
@Oppositional: да, я неоднократно проверял свой канал. Я был бы совершенно невежественен, если бы не был - я фактически использовал feedvalidator.org вместо валидатора w3, поскольку у него было много действительно конкретной помощи по всем возникающим вопросам. Фактически он функционировал как учебное пособие о том, как это сделать!   -  person David-W-Fenton    schedule 13.06.2011


Ответы (2)


Большинство потребителей каналов синдикации ожидают, что канал будет содержать относительно недавний контент, а ранее опубликованный контент «выпадет» из канала. Объем контента, который вы поддерживаете в ленте, обычно зависит от типа контента, который вы публикуете, но по мере увеличения размера вашего фида это может повлиять на способность клиентов фида извлекать и анализировать вашу информацию.

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

  1. Реализуйте разбиение на страницы и архивирование каналов, согласно RFC 5005, раздел 3, поскольку постраничные каналы могут быть полезны, когда количество записей очень велико, бесконечно или неопределенно. Клиенты могут "постранично" через канал, получая доступ только к подмножеству записей канала по мере необходимости.
  2. Логически разделите свой контент на несколько каналов и обеспечьте автоматическое обнаружение каналов на своем веб-сайте.
  3. Внедрите интерфейс службы на основе REST, который позволяет потребителям извлекать и фильтровать ваш контент как канал в формате Atom или RSS с представлением по умолчанию с использованием некоторых разумных значений по умолчанию.

Вариант 1 является разумным подходом только в том случае, если вы знаете тип клиентов канала, которые будут использовать ваш канал, поскольку не все клиенты каналов поддерживают разбиение на страницы.

Вариант 2 является наиболее распространенным на общедоступных веб-сайтах, поскольку большинство браузеров и клиентов поддерживают автоматическое обнаружение, и вы можете предоставить как полный исторический канал, так и более мелкий канал более свежего контента (или сегмент способами, которые имеют смысл для вашего контента).

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

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

Независимо от того, в каком направлении вы выберете, рассмотрите возможность внедрения условного GET в свои каналы; и понять потенциальных потребителей вашего синдицированного контента, чтобы выбрать наиболее подходящую стратегию. См. этот ответ, если вы решите, какой формат канала синдикации (s) вы хотите предоставить.

person Oppositional    schedule 07.06.2011
comment
На самом деле я реализовал фид как скрипт, поэтому я мог предоставить несколько субфидов. Я также установил LIMIT на SQL, который извлекает данные. В конце концов я понял, что предоставление всей ленты имело значение для меня только вначале, но, вероятно, не имело значения ни для кого из людей, подписавшихся на нее. Спасибо за отличный ответ. Я отложил несколько ваших цитат для дальнейшего изучения, особенно по вопросу предоставления последнего обновленного заголовка. - person David-W-Fenton; 09.06.2011

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

person Ignacio Vazquez-Abrams    schedule 07.06.2011