Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Being able to subscribe to updates

Aperta
  • Qualcosa non va?
#577 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
12/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Attiva
Ambito
api, backend

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

pending clarification

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).

Lingua principale
Python
Stelle
7
Fork
2
Merge medio
1g 9h
PR unite (30g)
33

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di openzim/cms

Tutte le issue di openzim/cms

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.