2011-03-15 18 views
6

Estoy implementando una fuente RSS para un sitio web y no entiendo ciertas cosas sobre el formato/tamaño/contenido del archivo XML para el feed.¿Qué tan grande es demasiado grande para un archivo XML de fuente RSS?

Estoy inicializando el sitio con los datos pasados, que se remontan a 1999 (no había alimentación en ningún momento hasta ahora), y solo se agregarán un par de cientos de elementos por año.

¿Hay algún protocolo para archivar, o solo puedo conservar el archivo y continuar añadiéndolo? Pensaría que sería ineficiente, ya que los agregadores tienen que descargar todo (supongo).

Entonces, ¿cuál es la costumbre habitual para esto? ¿Limitarlo al último mes? El archivo actual con más de 900 ítems es de 1.5MB, y espero que el valor de 1 año sea de aproximadamente 1/10 de ese tamaño o menos.

¿Alguna sugerencia sobre esto sobre qué principios usar y cómo implementarlo? Estoy usando PHP, pero mis datos son lo suficientemente complicados. Hice rodar mi propio script para escribir el archivo (y lo valida bien), así que no puedo usar una solución enlatada. Tengo que entender qué implementar en mi propio archivo. guión.

+1

¿Qué magia has realizado para que te respondan? ¡Hubiera sido mucho más útil para mí hace 3 meses! –

+0

Solía ​​ser un fanático de la sindicación, y la pregunta era más arquitectónica que técnica por naturaleza. Lo único que no mencioné es que asegure sus feeds finales a través de http://validator.w3.org/feed/ ¡esto les ahorrará a usted y a sus consumidores un montón de dolor de cabeza! – Oppositional

+0

@david He editado tu gramática ligeramente para no ofender a los usuarios y cuando editas la pregunta, la pregunta obtiene una clasificación más alta y más visibilidad –

Respuesta

5

La mayoría de los consumidores de feeds de sindicación tienen la expectativa de que el feed contenga contenido relativamente reciente, con el contenido publicado anteriormente 'cayendo' del feed. La cantidad de contenido que mantiene en el feed generalmente se basa en el tipo de contenido que publica, pero a medida que aumenta el tamaño de su feed, puede afectar la capacidad de los clientes de feed de recuperar y analizar su información.

Si realmente desea publicar una alimentación histórica que se añade continuamente, pero nunca tiene elementos de contenido eliminado, es posible que desee considerar las siguientes opciones (en base a las necesidades de sus consumidores):

  1. Implementar Feed Paging and Archiving, per RFC 5005 Section 3, ya que los feeds paginados pueden ser útiles cuando el número de entradas es muy grande, infinito o indeterminado. Los clientes pueden "localizar" a través de la fuente, solo accediendo a un subconjunto de las entradas de la fuente, según sea necesario.
  2. Segmente lógicamente su contenido en múltiples fuentes y proporcione auto-discovery a las fuentes de su sitio web.
  3. Implemente una interfaz de servicio basada en REST que permite a los consumidores recuperar y filtrar su contenido como un formato de alimentación Atom o RSS, con la representación predeterminada utilizando algunos valores predeterminados razonables.

Opción 1 es un enfoque razonable sólo si conoce el tipo de clientes de alimentación que va a estar consumiendo su alimento, ya que no todos los clientes de alimentación soportan paginación.

La opción 2 es la más común en sitios web públicos, ya que la mayoría de los navegadores y clientes admiten autodescubrimiento, y puede proporcionar un feed histórico completo y un feed de contenido más reciente (o segmento) formas que tengan sentido para su contenido).

Opción 3 potencialmente le permite proporcionar los beneficios de las dos primeras opciones, además de que puede proporcionar múltiples formatos de alimentación y un rico filtrado de su contenido. Es una forma muy poderosa de exponer el contenido del feed, pero por lo general solo vale la pena si sus consumidores indican que desean personalizar el contenido del feed que desean consumir.

Si bien la mayoría de los clientes de fuentes enriquecidas recuperarán el contenido de la fuente de manera asincrónica, los clientes que realizan solicitudes sincrónicas (y potencialmente frecuentes) pueden experimentar problemas de tiempo de espera a medida que aumenta el tamaño de la fuente.

Independientemente de la dirección que tome, considere implementar Conditional GET en sus feeds; y comprender a los consumidores potenciales de su contenido sindicado para elegir la estrategia que mejor se adapte a sus necesidades. Consulte this answer cuando tenga en cuenta qué formato de feed de sindicación desea proporcionar.

+0

De hecho terminé implementando el feed como script, por lo que pude proporcionar subenvíos múltiples. También coloqué un LÍMITE en el SQL que recupera los datos. Finalmente me di cuenta de que proporcionar el feed completo solo me importaba al principio, pero probablemente no le importó a ninguna de las personas que se suscribieron. Gracias por la excelente respuesta. He archivado varias de sus citas para una mayor investigación, particularmente sobre la cuestión de proporcionar un encabezado actualizado por última vez. –

0

Los agregadores descargarán el archivo repetidamente, por lo que limitar el tamaño es importante. Me gustaría que el feed contenga 10 elementos o que el elemento más antiguo tenga una semana de antigüedad, lo que proporcione más entradas, a menos que se anule con un parámetro GET. Por supuesto, esto variará según el uso real que veas de tus clientes, así como la actividad en el feed en sí.

Cuestiones relacionadas