Initial revision

doc/vad-aer-olaest.swe

+This swedish text describes how the client knows which texts the user
+has not yet read. It is extracted from the LysKOM-server that runs
+at lysator.liu.se.
+-------------------------------------------------------------------
+
+
+102868 1991-09-07  20:40  /132 rader/ ceder (Per Cederqvist  Lysator)
+Kommentar till text 102846 av Jonas S Karlsson (@Link ping enl CSN)
+Mottagare: LysKOM internals <1804>
+Markerad av dig och 2 andra.
+[rende: Hur man vet vad som {r ol{st.
+------------------------------------------------------------
+Varje person har en lista |ver vilka m|ten han {r med i. F|r varje
+m|te han {r med i lagras i en struct som vi kallar Membership:
+
+	* m|tesnumret
+	* prioriteten p} m|tet
+	* n{r man senast l{ste en text i m|tet (markerade en text i
+	  m|tet som l{st)
+	* vilka texter man har l{st (lokala m|tesnummer)
+	  Just nu lagras det som
+	
+		Local_text_no  last_text_read;
+		u_short	       no_of_read_texts;
+		Local_text_no *read_texts;
+
+	  vilket inneb{r att man har l{st alla texter fram till och
+	  med last_text_read, och dessutom alla texter som finns i den
+	  dynamiskt allokerade arrayen read_texts (som inneh}ller
+	  no_of_read_texts texter).
+
+query_read_texts tar som argument en person och ett m|te (som
+eventuellt kan vara en brevl}da) och returnerar den personens
+Membership f|r just det m|tet. Till protokoll B kommer vi att d|pa om
+funktionen till get_membership.
+
+> 102846 1991-09-07  17:05  /16 rader/ Jonas S Karlsson (@Link ping enl CSN)
+> Mottagare: LysKOM internals <1801>
+> [rende: Protokollet fr{ga...
+
+102846 {r ett globalt textnummer. Vi anv{nder typen Text_no f|r att
+lagra och hantera s}dana nummer. 1801 {r ett lokalt nummer f|r m|tet
+LysKOM internals. S}dana nummer lagras i en Local_text_no. (B}de
+Text_no och Local_text_no {r 32 bittar just nu).
+
+F|r varje m|te finns en relation MAP : Local_text_no -> Text_no.  Med
+anropet get_map kan man h{mta en tabell med vars hj{lp man kan g|ra den
+|vers{ttningen f|r ett visst m|te.
+
+
+get_created_texts ger en lista som inneh}ller de texter som en viss
+person har skrivit.
+
+F|r att ta reda p} vilka m|ten man har ol{sta inl{gg i g|r man s} h{r:
+
+1) get_unread_confs (ditt personnummer)
+
+Du f}r en lista med m|tesnummer. LysKOM garanterar att du inte har
+n}got ol{st i n}got annat m|te, men det kan h{nda att den ger tillbaks
+n}gra m|ten som du i verkligheten inte har n}got ol{st i.
+
+De m|ten man f}r tillbaks {r de d{r de existerar (eller har existerat)
+en text med ett h|gre lokalt textnummer {n last_text_read i ditt
+Membership i m|tet i fr}ga.
+
+2a) G|r query_read_texts f|r alla m|ten i listan du fick i steg 1.
+
+2b) Samtidigt h{mtar du m|tesstatusen f|r de m|tena (med
+get_conf_stat).
+
+3) Samla ihop alla svaren och sortera dom s} att man f}r l{sa
+inl{ggen i r{tt ordning.
+
+4) Ta det f|rsta m|tet. J{mf|r det h|gsta lokala numret som existerar
+(det kan du f} fram ur m|tesstatusen) med last_text_read i ditt
+Membership. Om det visar sig att det finns texter du inte har l{st
+m}ste du g|ra ett get_map f|r att ta reda p} vilket globalt textnummer
+de ol{sta texterna har.
+
+5) Sl} upp varje lokalt textnummer som du inte har l{st i mappen. Du
+f}r ett Text_no. Om du f}r en nolla inneb{r det att den text som hade
+det numret har raderats eller subtraherats fr}n m|tet. Ignorera det
+lokala numret och tag n{sta.
+
+6) N{r du f}r ett textnummer som inte {r noll h{mtar du textstatusen
+och textmassan (sj{lva texten) med get_text_stat och get_text, och
+visar den p} sk{rmen. N{r anv{ndaren har l{st klart texten talar du om
+det f|r servern med mark_as_read (som tar ett m|tesnummer och ett
+Local_text_no som argument och uppdaterar ditt Membership f|r det
+m|tet). Om texten har flera mottagare som du {r medlem i ska du anropa
+mark_as_read en g}ng f|r varje mottagare.
+
+Repetera steg 5 och 6 tills du har l{st ut m|tet. Se till att du
+f|ljer kommentartr{det, om anv{ndaren vill det.
+
+Repetera steg 4 tills allt {r utl{st.
+
+Visa alla markerade.
+
+Se tiden.
+=================================================================
+
+S} g}r det till, grovt sett. Saker och ting kompliceras av att det
+hela tiden skrivs nya texter. Servern skickar ut ett asynkront
+meddelande n{r en ny text skapas (i ett m|te som man {r medlem i). I
+meddelandet finns hela textstatusen (s} att man slipper h{mta den).
+
+En annan grej som g|r det hela komplicerat {r att man g{rna vill att
+klienten ska h{mta saker i f|rv{g n{r man inte har n}got annat att
+g|ra. Man vill att klienten inte ska h{mta samma information mer {n en
+g}ng. Man vill f} upp den f|rsta texten s} snabbt som m|jligt. Man
+vill kunna g|ra Lista Nyheter s} snabbt som m|jligt. Det finns m}nga
+saker man kan optimera p} olika s{tt.
+
+Elispklienten g|r inte riktigt som jag har beskrivit det p} alla
+st{llen, men resultatet blir i princip det samma. En del av anropen
+(t ex get_unread_confs) har vi inf|rt i efterhand f|r att vi m{rkte
+att det var n|dv{ndigt f|r att f} saker och ting att g} n}gorlunda
+snabbt.
+
+Vi har medvetet valt att g|ra s} mycket jobb som m|jligt i klienten,
+och s} lite jobb som m|jligt i servern. Nu, n{r det blev s} att
+klienten {r skriven i elisp, s} skulle vi nog ha f}tt ett snabbare
+system (s{rskilt uppstarten) om servern varit mer intelligent och valt
+i vilken ordning texter ska visas. Systemet {r designat med m}let att
+det inte ska bli l}ngsammare {ven om m}nga klienter kopplar upp sig
+samtidigt, och det m}let har vi nog n}tt. (Att det kan g} l}ngsamt n{r
+5-6 personer k|r sin elispklient p} lysator.liu.se beror inte p}
+svarstiderna fr}n LysKOM-servern, utan p} att emacsarna blir
+l}ngsamma. De som k|r fr}n en obelastad maskin samtidigt m{rker inte
+att det g}r l}ngsamt (skryt, skryt:-)). (Nej, det finns inga m{tningar
+som bekr{ftar det h{r - men jag t{nker m{ta lite responstider senare i
+h|st).
+
+Med en smart klient skriven i c kommer LysKOM att bli snabbt. Om
+c-klienterna k|rs p} varsin maskin (var och en har sin egen
+arbetsstation) tror jag att systemet kommer att klara "tillr{ckligt"
+m}nga anv{ndare. (LysKOM {r ju ett lokalt media. Om hela v{rlden k|rde
+p} samma LysKOM-server i st{llet f|r att skriva news skulle det bli
+olidligt att l{sa LysKOM {ven om man bortser fr}n responstider...)
+
+P}peka g{rna eventuella oklarheter i den h{r texten. Jag t{nker skicka
+med den bland dokumentationen vi har i serverreleasen som vi snart
+g|r, s} jag vill att texten ska vara begriplig...
+(102868) -----------------------------------

doc/what-is-unread.swe

+This swedish text describes how the client knows which texts the user
+has not yet read. It is extracted from the LysKOM-server that runs
+at lysator.liu.se.
+-------------------------------------------------------------------
+
+
+102868 1991-09-07  20:40  /132 rader/ ceder (Per Cederqvist  Lysator)
+Kommentar till text 102846 av Jonas S Karlsson (@Link ping enl CSN)
+Mottagare: LysKOM internals <1804>
+Markerad av dig och 2 andra.
+[rende: Hur man vet vad som {r ol{st.
+------------------------------------------------------------
+Varje person har en lista |ver vilka m|ten han {r med i. F|r varje
+m|te han {r med i lagras i en struct som vi kallar Membership:
+
+	* m|tesnumret
+	* prioriteten p} m|tet
+	* n{r man senast l{ste en text i m|tet (markerade en text i
+	  m|tet som l{st)
+	* vilka texter man har l{st (lokala m|tesnummer)
+	  Just nu lagras det som
+	
+		Local_text_no  last_text_read;
+		u_short	       no_of_read_texts;
+		Local_text_no *read_texts;
+
+	  vilket inneb{r att man har l{st alla texter fram till och
+	  med last_text_read, och dessutom alla texter som finns i den
+	  dynamiskt allokerade arrayen read_texts (som inneh}ller
+	  no_of_read_texts texter).
+
+query_read_texts tar som argument en person och ett m|te (som
+eventuellt kan vara en brevl}da) och returnerar den personens
+Membership f|r just det m|tet. Till protokoll B kommer vi att d|pa om
+funktionen till get_membership.
+
+> 102846 1991-09-07  17:05  /16 rader/ Jonas S Karlsson (@Link ping enl CSN)
+> Mottagare: LysKOM internals <1801>
+> [rende: Protokollet fr{ga...
+
+102846 {r ett globalt textnummer. Vi anv{nder typen Text_no f|r att
+lagra och hantera s}dana nummer. 1801 {r ett lokalt nummer f|r m|tet
+LysKOM internals. S}dana nummer lagras i en Local_text_no. (B}de
+Text_no och Local_text_no {r 32 bittar just nu).
+
+F|r varje m|te finns en relation MAP : Local_text_no -> Text_no.  Med
+anropet get_map kan man h{mta en tabell med vars hj{lp man kan g|ra den
+|vers{ttningen f|r ett visst m|te.
+
+
+get_created_texts ger en lista som inneh}ller de texter som en viss
+person har skrivit.
+
+F|r att ta reda p} vilka m|ten man har ol{sta inl{gg i g|r man s} h{r:
+
+1) get_unread_confs (ditt personnummer)
+
+Du f}r en lista med m|tesnummer. LysKOM garanterar att du inte har
+n}got ol{st i n}got annat m|te, men det kan h{nda att den ger tillbaks
+n}gra m|ten som du i verkligheten inte har n}got ol{st i.
+
+De m|ten man f}r tillbaks {r de d{r de existerar (eller har existerat)
+en text med ett h|gre lokalt textnummer {n last_text_read i ditt
+Membership i m|tet i fr}ga.
+
+2a) G|r query_read_texts f|r alla m|ten i listan du fick i steg 1.
+
+2b) Samtidigt h{mtar du m|tesstatusen f|r de m|tena (med
+get_conf_stat).
+
+3) Samla ihop alla svaren och sortera dom s} att man f}r l{sa
+inl{ggen i r{tt ordning.
+
+4) Ta det f|rsta m|tet. J{mf|r det h|gsta lokala numret som existerar
+(det kan du f} fram ur m|tesstatusen) med last_text_read i ditt
+Membership. Om det visar sig att det finns texter du inte har l{st
+m}ste du g|ra ett get_map f|r att ta reda p} vilket globalt textnummer
+de ol{sta texterna har.
+
+5) Sl} upp varje lokalt textnummer som du inte har l{st i mappen. Du
+f}r ett Text_no. Om du f}r en nolla inneb{r det att den text som hade
+det numret har raderats eller subtraherats fr}n m|tet. Ignorera det
+lokala numret och tag n{sta.
+
+6) N{r du f}r ett textnummer som inte {r noll h{mtar du textstatusen
+och textmassan (sj{lva texten) med get_text_stat och get_text, och
+visar den p} sk{rmen. N{r anv{ndaren har l{st klart texten talar du om
+det f|r servern med mark_as_read (som tar ett m|tesnummer och ett
+Local_text_no som argument och uppdaterar ditt Membership f|r det
+m|tet). Om texten har flera mottagare som du {r medlem i ska du anropa
+mark_as_read en g}ng f|r varje mottagare.
+
+Repetera steg 5 och 6 tills du har l{st ut m|tet. Se till att du
+f|ljer kommentartr{det, om anv{ndaren vill det.
+
+Repetera steg 4 tills allt {r utl{st.
+
+Visa alla markerade.
+
+Se tiden.
+=================================================================
+
+S} g}r det till, grovt sett. Saker och ting kompliceras av att det
+hela tiden skrivs nya texter. Servern skickar ut ett asynkront
+meddelande n{r en ny text skapas (i ett m|te som man {r medlem i). I
+meddelandet finns hela textstatusen (s} att man slipper h{mta den).
+
+En annan grej som g|r det hela komplicerat {r att man g{rna vill att
+klienten ska h{mta saker i f|rv{g n{r man inte har n}got annat att
+g|ra. Man vill att klienten inte ska h{mta samma information mer {n en
+g}ng. Man vill f} upp den f|rsta texten s} snabbt som m|jligt. Man
+vill kunna g|ra Lista Nyheter s} snabbt som m|jligt. Det finns m}nga
+saker man kan optimera p} olika s{tt.
+
+Elispklienten g|r inte riktigt som jag har beskrivit det p} alla
+st{llen, men resultatet blir i princip det samma. En del av anropen
+(t ex get_unread_confs) har vi inf|rt i efterhand f|r att vi m{rkte
+att det var n|dv{ndigt f|r att f} saker och ting att g} n}gorlunda
+snabbt.
+
+Vi har medvetet valt att g|ra s} mycket jobb som m|jligt i klienten,
+och s} lite jobb som m|jligt i servern. Nu, n{r det blev s} att
+klienten {r skriven i elisp, s} skulle vi nog ha f}tt ett snabbare
+system (s{rskilt uppstarten) om servern varit mer intelligent och valt
+i vilken ordning texter ska visas. Systemet {r designat med m}let att
+det inte ska bli l}ngsammare {ven om m}nga klienter kopplar upp sig
+samtidigt, och det m}let har vi nog n}tt. (Att det kan g} l}ngsamt n{r
+5-6 personer k|r sin elispklient p} lysator.liu.se beror inte p}
+svarstiderna fr}n LysKOM-servern, utan p} att emacsarna blir
+l}ngsamma. De som k|r fr}n en obelastad maskin samtidigt m{rker inte
+att det g}r l}ngsamt (skryt, skryt:-)). (Nej, det finns inga m{tningar
+som bekr{ftar det h{r - men jag t{nker m{ta lite responstider senare i
+h|st).
+
+Med en smart klient skriven i c kommer LysKOM att bli snabbt. Om
+c-klienterna k|rs p} varsin maskin (var och en har sin egen
+arbetsstation) tror jag att systemet kommer att klara "tillr{ckligt"
+m}nga anv{ndare. (LysKOM {r ju ett lokalt media. Om hela v{rlden k|rde
+p} samma LysKOM-server i st{llet f|r att skriva news skulle det bli
+olidligt att l{sa LysKOM {ven om man bortser fr}n responstider...)
+
+P}peka g{rna eventuella oklarheter i den h{r texten. Jag t{nker skicka
+med den bland dokumentationen vi har i serverreleasen som vi snart
+g|r, s} jag vill att texten ska vara begriplig...
+(102868) -----------------------------------