api - feedreader - ¿Cómo saltarse las entradas conocidas al sincronizar con Google Reader?

google reader español (2)

para escribir un cliente fuera de línea en el servicio de Google Reader, me gustaría saber cómo sincronizar mejor con el servicio.

Todavía no parece haber documentación oficial y la mejor fuente que encontré hasta ahora es la siguiente: http://code.google.com/p/pyrfeed/wiki/GoogleReaderAPI

Ahora considere esto: con la información de arriba, puedo descargar todos los elementos no leídos, puedo especificar cuántos elementos descargar y usar el identificador atom, puedo detectar entradas duplicadas que ya descargué.

Lo que me falta es una forma de especificar que solo quiero las actualizaciones desde mi última sincronización. Puedo decir darme las 10 (parámetro n = 10) últimas entradas (parámetro r = d). Si especifico el parámetro r = o (fecha ascendente) entonces también puedo especificar el parámetro ot = [última hora de sincronización], pero solo entonces y el orden ascendente no tiene sentido cuando solo quiero leer algunos elementos versus todos artículos.

¿Alguna idea de cómo resolver eso sin descargar todos los elementos nuevamente y solo rechazar los duplicados? No es una forma muy económica de sondeo.

Alguien propuso que puedo especificar que solo quiero las entradas no leídas. Pero para hacer que esa solución funcione de la manera en que Google Reader no volverá a ofrecer estas entradas, necesitaría marcarlas como leídas. A su vez, eso significaría que debo mantener mi propio estado de lectura / no leído en el cliente y que las entradas ya están marcadas como leídas cuando el usuario inicia sesión en la versión en línea de Google Reader. Eso no funciona para mí.

Saludos, Mariano

La API de Google aún no se ha publicado, momento en el que esta respuesta puede cambiar.

En la actualidad, tendrías que llamar a la API y desestimar los elementos que ya descargaste, lo que, como dijiste, no es muy eficiente ya que volverás a descargar los elementos todo el tiempo, incluso si ya los tienes.

Para obtener las últimas entradas, use la descarga estándar desde la más reciente fecha de bajada, que comenzará desde las últimas entradas. Recibirá un token de "continuación" en el resultado de XML, luciendo algo como esto:

<gr:continuation>CArhxxjRmNsC</gr:continuation>`

Examine los resultados y saque algo nuevo para usted. Debería encontrar que todos los resultados son nuevos o que todo hasta cierto punto es nuevo, y que todos los demás ya los conocen.

En este último caso, ya terminaste, pero en el primero necesitas encontrar algo nuevo más antiguo que lo que ya has recuperado. Haga esto usando la continuación para obtener los resultados empezando justo después del último resultado en el conjunto que acaba de recuperar pasándolo en la solicitud GET como el parámetro c , por ejemplo:

http://www.google.com/reader/atom/user/-/state/com.google/reading-list?c=CArhxxjRmNsC

Continúa de esta manera hasta que tengas todo.

El parámetro n , que es un recuento del número de elementos que se recuperarán, funciona bien con esto y puede cambiarlo sobre la marcha. Si la frecuencia de la comprobación es configurada por el usuario, y por lo tanto podría ser muy frecuente o muy rara, puede usar un algoritmo adaptativo para reducir el tráfico de la red y su carga de procesamiento. Inicialmente solicite un número pequeño de las últimas entradas, digamos cinco (agregue n=5 a la URL de su solicitud GET). Si todos son nuevos, en la próxima solicitud, donde usa la continuación, solicite un número mayor, por ejemplo, 20. Si aún son nuevos, o el feed tiene muchas actualizaciones o ha pasado un tiempo, continúe en grupos de 100 o lo que sea.

Sin embargo, y corríjame si me equivoco aquí, también querrás saber, después de que hayas descargado un elemento, si su estado cambia de "no leído" a "leído" debido a que la persona lo lee usando la interfaz de Google Reader.

Un enfoque para esto sería:

Actualice el estado en google de cualquier elemento que se haya leído localmente.
Verifique y guarde el conteo no leído del feed. (Desea hacer esto antes del próximo paso, para garantizar que no hayan llegado nuevos elementos entre la descarga de los elementos más nuevos y la hora en que verifica el recuento de lectura).
Descargue los últimos artículos.
Calcule su cuenta de lectura y compárela con la de Google. Si el feed tiene un recuento de lectura más alto que el calculado, sabrá que algo se ha leído en google.
Si se ha leído algo en google, comience a descargar elementos leídos y a compararlos con su base de datos de elementos no leídos. Encontrará algunos elementos que Google dice que se leen que las afirmaciones de su base de datos no se han leído; actualizar estos. Continúe haciéndolo hasta que haya encontrado una cantidad de estos elementos igual a la diferencia entre su cuenta de lectura y la de Google, o hasta que las descargas no sean razonables.
Si no encontró todos los artículos leídos, c''est la vie ; registre el número restante como un total "no encontrado sin leer" que también debe incluir en su próximo cálculo del número local que cree que no se ha leído.

Si el usuario se suscribe a muchos blogs diferentes, también es probable que los etiquete de forma extensa, por lo que puede hacer todo esto por etiqueta en lugar de hacerlo para todo el feed, lo que debería ayudar a mantener baja la cantidad de datos, ya que no será necesario realizar ninguna transferencia para las etiquetas en las que el usuario no haya leído nada nuevo en Google Reader.

Este esquema completo se puede aplicar a otros estados, como el de estrella o el de estrella.

Ahora, como dices, esto

... significaría que necesito mantener mi propio estado de lectura / no leído en el cliente y que las entradas ya están marcadas como leídas cuando el usuario inicia sesión en la versión en línea de Google Reader. Eso no funciona para mí.

Suficientemente cierto. Ni mantener un estado de lectura / no leída local (ya que mantiene una base de datos de todos los elementos de todos modos) ni marcar elementos leídos en google (que la API admite) parece muy difícil, entonces, ¿por qué no funciona para usted?

Sin embargo, hay otro inconveniente: el usuario puede marcar algo leído como no leído en google. Esto arroja un poco de llave en el sistema. Mi sugerencia allí, si realmente quieres tratar de encargarse de esto, es suponer que el usuario en general tocará solo cosas más recientes, y descargará los últimos cientos de artículos cada vez, verificando el estado de todos ellos. (Esto no es tan malo, la descarga de 100 elementos me llevó desde 0.3s para 300KB, hasta 2.5s para 2.5MB, aunque con una conexión de banda ancha muy rápida).

Nuevamente, si el usuario tiene una gran cantidad de suscripciones, probablemente también tenga un número razonablemente grande de etiquetas, por lo que hacerlo por etiqueta acelerará las cosas. En realidad, sugeriría que no solo controle por etiqueta, sino que también distribuya los cheques, verificando una sola etiqueta cada minuto en lugar de una vez cada veinte minutos. También puede hacer este "gran control" para cambios de estado en elementos más antiguos con menos frecuencia que cuando hace un control de "cosas nuevas", tal vez una vez cada dos horas, si desea mantener el ancho de banda bajo.

Esto es un poco de cerdo de ancho de banda, principalmente porque necesita descargar el artículo completo de Google simplemente para verificar el estado. Lamentablemente, no veo ninguna forma de evitarlo en los documentos API que tenemos disponibles. Mi único consejo real es minimizar la verificación de estado en artículos no nuevos.