Skip to content
GitLab
Projects
Groups
Snippets
/
Help
Help
Support
Community forum
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
Menu
Open sidebar
Per Cederqvist
lyskom-server-ceder-1616-generations-topgit
Commits
f7d27737
Commit
f7d27737
authored
Sep 13, 1991
by
Per Cederqvist
Browse files
Initial revision
parent
9cb67140
Changes
2
Hide whitespace changes
Inline
Side-by-side
doc/vad-aer-olaest.swe
0 → 100644
View file @
f7d27737
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
0 → 100644
View file @
f7d27737
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) -----------------------------------
Write
Preview
Supports
Markdown
0%
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment