Wachten op nieuws, als uitbreiding van de inbox (shaer-n05)
Geen tweede endpoint. Geef since (de shaer:cursor uit je vorige antwoord) en
wait mee aan de bestaande inbox-lezing, en het antwoord blijft hangen tot er
iets is of de tijd om is. Zonder die twee gedraagt de route zich exact zoals
altijd.
Bewust hetzelfde antwoord in plaats van een 'er is nieuws'-seintje: dan hoeft de
client niets nieuws te parsen, is er geen tweede beschrijving van de kaartvorm
die uit de pas kan lopen met de eerste, en scheelt het een tweede ronde.
De merksteen telt ALLE VIER de poten die de inbox samenvoegt: tijdlijn,
berichten, antwoorden op je eigen posts, en wat je zelf verstuurde. Ontbreekt er
een, dan blijft een wachtende client slapen terwijl er wel degelijk nieuws is --
erger dan niet wachten, want het lijkt te werken. rowid en geen tijdstempel: die
loopt strikt op, terwijl twee dingen in dezelfde seconde kunnen aankomen en een
published van een andere server niet te vertrouwen is.
Wachten gebeurt met een interne tik en niet met een gebeurtenis-emitter. Een
emitter moet op ELKE plek worden aangeroepen waar er iets bijkomt, en de plek die
je vergeet is precies de melding die nooit aankomt. Vier MAX(rowid)-queries per
seconde is niets, en dit kan niets missen. Prijs: hooguit een tik vertraging.
Grenzen: hooguit 50 seconden wachten (ruim onder wat een proxy toestaat), vier
gelijktijdige wachters per account, en ophangen breekt het wachten af. Een client
met een kapotte herverbind-lus krijgt gewoon de huidige stand in plaats van een
fout.
9 tests, waaronder de vier poten apart en de vraag of hij wakker wordt in plaats
van de tijd vol te maken. Suite 537/537.
![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png){kind=logo}
