Being able to subscribe to updates
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 12/100
Línea de trabajo
This is a design question, not a patch: the issue asks whether catalog clients should subscribe to updates over SSE or websockets, and whether the payload should be ad hoc JSON or OPDS entries with a removal convention. Start with the earlier discussion in #265 and with how the current polling flow works for catalog retriever and the bittorrent tracker and seeder. Done means maintainers agree on a transport and format, not that code exists.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Now that the Catalog is managed in a centralized DB/service, we should be able to get instant updates instead of relying on the old scheme of polling the API, checking if it has been updated, then parsing the whole thing. It was approached in #265.
That ticket was about stateless requests but there's a growing pattern of constantly watching catalog services:
- catalog retriever (staging)
- catalog retriever (prod)
- bittorrent tracker
- bittorrent seeder could work this way also.
For such catalog clients, being able to subscribe to updates would make a lot more sense. There are several ways to implement this but I believe SSE or even websocket are well suited for the transport part of this. SSE is simpler on both side of the connection and has this LastEventId concept so I'd look at it first.
Then there's the format, we could either use something adhoc (JSON) or send valid OPDS entries (which custom handling for removal).
- Lenguaje dominante
- Python
- Estrellas
- 7
- Forks
- 3
- Merge medio
- 1 d 9 h
- PR fusionados (30 d)
- 30
Preparar el entorno
Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de openzim/cms
-
No value assigned to `full` mwoffliner recipe.Quizá libre de nuevo @benoit74 la tomó hace 29 días y no hay ningún pull request abierto. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
openzim/cms#472 · 6 comentarios · 1 asignado ·
Los mantenedores suelen responder en 1 día
-
Update documentation around rolesPosiblemente ocupada @elfkuzco la tomó hace 1 día. Abierto
openzim/cms#615 · 1 asignado ·
Los mantenedores suelen responder en 1 día
-
Dificultad 4/5 3-5 días Aptitud para principiantes 48/100
Los mantenedores suelen responder en 1 día
-
Upgrade dependencies, especially Node.JS 26, Python 3.15, Debian trixiePosiblemente ocupada @elfkuzco la tomó hace 3 días. Abierto
openzim/cms#609 · 1 asignado ·
Los mantenedores suelen responder en 1 día
-
pending clarification
Dificultad 3/5 1-2 días Aptitud para principiantes 55/100
openzim/cms#603 · 7 comentarios ·
Los mantenedores suelen responder en 1 día
Todos los issues de openzim/cms
Issues similares
-
style: article/section 📝 system: cloud.rc ☁️ system: security 🔐
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
uabrc/uabrc.github.io#1262 ·
-
documentation
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
NCAR/miles-credit#526 ·
-
documentation
Dificultad 1/5 1-3 horas Aptitud para principiantes 76/100
conda/conda-lock#957 ·
Los mantenedores suelen responder en 1 día
-
Type: Bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
aws-samples/sample-per-model-bedrock#464 ·
Los mantenedores suelen responder en 1 día