Skip to content

GitLab

Commit bfa4c83a authored by David Byers's avatar David Byers
Browse files

Removed outdated files.

parent a07f6fcd
Hide whitespace changes
Inline Side-by-side
doc/ideer/cache deleted 100644 → 0
View file @ a07f6fcd
/* Linus Tue May 8 20:49:06 MET DST 1990 */
cache komma ih}g
Gr{nssnittet mellan cache och ldb m}ste specificeras.
Mina ideer {r att varje anrop i ldb borde f|ljas av ett,
n{stan identiskt anrop i cache som g|r samma sak fast ih}gkommet.
Samma parametrar borde skickas ocks} s} att det inte beh|vs f|r mycket
ny doc.
Hmm folk har ju redan jobbat med detta. Jag dyker vidare ---->
Jag skall g|ra en tabell:
ldb funktioner cache funktioner
ldb_open ( void ); saknar motsvarighet
ldb_close ( void ); saknar motsvarighet
bool ldb_create_person ( Pers_no pers_no, Person * person ); bool cached_create_person ( Pers_no pers_no, Person * person ); cached_create_person
Person * ldb_read_person ( Pers_no pers_no ); Person * cached_read_person ( Pers_no pers_no );
bool ldb_update_person ( Pers_no pers_no, Person * person ); bool cached_update_person ( Pers_no pers_no, Person * person );
bool ldb_delete_person ( Pers_no pers_no ); bool cached_delete_person ( Pers_no pers_no );
Conf_no ldb_create_conf ( Conference * conference ); Conf_no cached_create_conf ( Conference * conference );
Conference * ldb_read_conf ( Conf_no conf_no ); Conference * cached_read_conf ( Conf_no conf_no );
bool ldb_update_conf ( Conf_no conf_no, Conference * conference ); bool cached_update_conf ( Conf_no conf_no, Conference * conference );
bool ldb_delete_conf ( Conf_no conf_no ); bool cached_delete_conf ( Conf_no conf_no );
Text_no ldb_create_tstat ( Text_stat * text_stat ); Text_no cached_create_tstat ( Text_stat * text_stat );
Text_stat * ldb_read_tstat ( Text_no text_no ); Text_stat * cached_read_tstat ( Text_no text_no );
bool ldb_update_tstat ( Text_no text_no, Text_stat * text_stat ); bool cached_update_tstat ( Text_no text_no, Text_stat * text_stat );
bool ldb_delete_tstat ( Text_no text_no ); bool cached_delete_tstat ( Text_no text_no );
Text_index ldb_create_text ( String text ); Text_index cached_create_text ( String text );
String ldb_read_text ( Text_index text_offset ); String cached_read_text ( Text_index text_offset );
bool ldb_delete_text ( Text_index text_offset ); bool cached_delete_text ( Text_index text_offset );
doc/ideer/cache-tankar deleted 100644 → 0
View file @ a07f6fcd
Senast {ndrad av Linus Wed May 9 20:19:54 MET DST 1990
Nu skall vi se om jag kan r{ta ut mina(=Linus) tankebanor:
cache komma ih}g.
Cachen kommer ih}g lite av varje s} att detta inte beh|ver h{mtas fr}n
disk varje g}ng.
Jag(=Linus) anser att det som b|r kommas ih}g {r ungef{r det som man
ville }t senast. Och kanske att n}gra objekt som man verkligen vet
refereras till ofta samt {r relativt sm} kanske ocks} borde cachas.
Vi skall se vilka olika typer av objekt som finns:
Conf_list
Conference
Person
Text_stat
undertyper till dessa.
Connection sparas inte p} disk. Skall cache ta hand om detta eller
skall det finnas n}gon annanstans. Cachen beh|ven nog
tillg}ng till denna information i alla fall.
F|r varje objekt som {r cachat m}ste lagras:
- hela dataarean
- om huruvida den {r uppdaterad p} skivan
- om huruvida detta objekt f}r flyttas i minnet.
- senaste g}ngen n}gon tittade p} denna post. (det r{cker faktiskt
med att h}lla reda p} ordningen i vilken de olika cachade
enheterna anv{ndes men d} kan kanske inte storleken anv{ndas f|r
optimering)
- storleken p} det lagrade objektet. (f|r att optimera sj{lva
cache-funktionen g{ller det ju att minimera kvadraten av den tid
varje byte ligger i minnet i on|dan mellan }tkomsterna.
Snabbheten som vinns med cachening {r ju sedan bara begr{nsad av
hur mycket minnesarea man har tillg}ng till.)
F|r varje typ av vilka n}gra {r cachade m}ste lagras:
- en index-lista p} vilka som finns cachade (kanske hashtabell s}
att man snabbt kan hitta den men det {r nog on|digt).
Vilka objekt m}ste eller borde finnas i minnet alltid?
(Alltid i detta fall {r v{l mellan tv} "atomiska" anrop.)
Conf_list Ja, redan klart
Conference Nej inte tvunget.
Person De som {r inloggade. (Krav finns redan p} detta pga
strukturen av Connection-structen.)
Connection Ja, finns ju inte p} disk :-).
Text_stat Nej.
Vilka objekt skall man str{va efter att ha i minnet f|r att ha i
minnet alltid? (F|r att vinna tid naturligtvis)
Conf_list Ja, ingen kommentar beh|vs
Conference Man borde kunna f|rs|ka att alltid ha de
konferenser som en anv{ndare kommer till n{sta
g}ng i minnet alltid.
Jag(=Linus) skulle egentligen vilja g} s} l}ngt att jag
|nskar att man kunde ha alla m|ten som n}gon
inloggad person har ol{sta inl{gg i inne.
Det borde inte vara speciellt sv}rt att h}lla reda
p} n{r det skapas nya inl{gg och d} m}ste v{l {nd}
de m|tet l{sas in s} det blir bara sm} problem.
N{r (och var) sker egentligen kollen efter nya
nyheter i m|ten personen inte {r i. Det borde vara
n{r han skall g} till n{sta m|te. Jag(=Linus)
hittar inte denna s} jag misst{nker att det inte
{r klart.
L}t oss str{va efter detta:
F|r varje person som {r inloggat finns Person
Connection och Conference som han {r i och
Conference som han kommer till n{sta g}ng i
minnet.
Person Bara de som {r inloggade. Det finns v{l ingen
anledning att f|rs|ka gissa sig till vem som
kommer att logga in h{rnest eller vem som kommer
att fr}gas efter statusen p}.
#if det_fungerar_som_jag_trodde
D{remot skulle det kanske vara trevligt om man
hade en lista p} alla personers namn i minnet
alltid s} att man inte beh|ver l{sa in namnet n{r
n}gon vill l{sa en text.
#endif
Connection :-)
Text_stat Det vore bra om statusen f|r n{sta text fanns inne
i minnet. N{sta text {r n{sta text en person vill
l{sa.
[nnu b{ttre vore om status f|r alla texter som
varje inloggad person har ol{sta i ett m|te samt
status f|r alla som de ol{sta kommenterar samt
f|rsta (5-50) ol{sta i n{sta m|te som varje person
kommer till.
Texter Texten f|r n{sta inl{gg som personen kommer till
samt till inl{gget som kommentera av aktuellt
inl{gg vore bra att ha inne redan.
Kanske {ven texten f|r f|rsta inl{gget i n{sta m|te.
\ No newline at end of file
doc/ideer/cache.spec deleted 100644 → 0
View file @ a07f6fcd
(233878) 90-05-29 10.04 /64 rader/ ceder (Per Cederqvist/p 334)
Mottagare: LysKom implementationsdiskussion (m 376) <309>
Markerad av: ceder (Per Cederqvist/p 334)
Markerad av 2 andra personer.
[rende: cache
------------------------------------------------------------
Heureka! Jag har funnit det!
Nu vet jag hur vi ska veta vad vi kan sl{nga ut, vad som {r modifierat,
vad som vi b|r h}lla kvar i minnet till varje pris, vad vi m}ste
h}lla kvar till slutet p} detta atomiska anrop. L|sningen {r
simpel n{r man v{l kommer p} den. L|sningen kom till mig alldeles
nyss n{r jag l}g i min s{ng och funderade p} om jag skulle g}
upp eller f|rs|ka forts{tta sova mitt i allt ov{sen. (De byter
sopnedkast :-( ) Nu ska vi se om jag kan lugna ner mig s} att
jag kan skriva in h{r. Om ni inte f|rst}r n}got av vad jag skriver
h{r, s} f|rtvivla icke. Jag har det nerskrivet p} papper ocks},
jag kommer i alla fall att kunna tyda det och minnas min ide....
typedef struct {
Pers_node *prev, *next;
Person *person;
u_char ref_count;
Bool is_dirty;
time_t first_modified;
Pers_node *next_dirty;
} Pers_node;
F|r varje Person-struct som man har i minnet har man en motsvarande
Pers_node. Med hj{lp av f{lten prev/next skapar man tre (3) dubbell{nkade
listor:
I) Objekt som ej refereras just nu.
II) Objekt som l{mnats ut under detta atomiska anrop.
III) Objekt som {r l}sta i minnet. (Inloggade personer, m|ten
som folk befinner sig i.)
login() |kar ref_count och l{gger in personen sist p} lista III.
logout() minskar ref_count, och om den blev 0 s} flyttar den
personen till lista II.
I slutet av varje atomiskt anrop anropas en funktion som flyttar
alla objekt i lista II till lista I.
mark_person_as_changed() kolla is_dirty-bitten. Om objektet redan
var dirty s} g|rs ingenting. Annars l{ggs objektet in sista p}
dirty-listan (next_dirty), first_modified = time(NULL);
N{r man beh|ver mer plats {r det bara att ta det f|rsta objektet
p} lista I som inte {r dirty och sl{nga det.
Efter varje atomiskt anrop s} sparar man alla eller de flesta
objekten p} dirty-listan. Det kan kanske vara l{mpligt att anv{nda
f|ljande villkor f|r att kolla om det {r dags att spara eller
inte:
if ( ref_count == 0 || time() - first_modified > SYNC_INTERVAL)
write_it();
Jo, en sak till. Pers_node:erna flyttar aldrig p} sig. Det {r
bara pekarna som {ndras. F|r att hitta fr}n ett nummer till en
visst person har man n}gon form av hash-tabell som pekar p} Pers_node:erna.
N{r jag t{nker efter beh|ver man kanske ha med
Pers_no pers_no;
i Pers_node-structen.
L}ter det h{r vettigt, eller sover jag fortfarande?
/ceder
(Text 233878)------------------------------
(Kommentar i (Text 233935) av Pell Pell Pell)
doc/ideer/prot-B-analys deleted 100644 → 0
View file @ a07f6fcd
Filen doc/prot-B-analys
Bellman hackade mera 1990-12-19, efter fysiskt m|te under kv{llen.
Aronsson was here
20 oktober 1990
LysKOM Analys
--------------------------------
Protokoll B mellan klient och server
--------------------------------
av Lars Aronsson
<Aronsson@Lysator.LiU.SE>
LysKOM
LysKOM {r ett datakonferenssystem. Andra liknande system {r QZ-KOM och
PortaCOM. LysKOM {r Copyright (C) 1990, 1991 datorf|reningen Lysator vid
Universitetet och Tekniska H|gskolan i Link|ping. Var och en till}ts
fritt kopiera, {ndra och distribuera LysKOM dokument och program,
givet att mottagarna ges samma r{ttigheter. Varken Lysator eller dess
medlemmar tar n}got som helst ansvar f|r dokumentens eller programmens
riktighet eller f|ljderna av deras anv{ndande.
Den h{r texten
Den h{r texten {r en analys inf|r specifierandet av version B av det
protokoll som anv{nds mellan en klient (anv{ndarens program) och en
server (databasen).
Multimedia
F|r att kunna inf|ra multimedia i LysKOM, g}r vi |ver fr}n att ha
texter till att ha generella inl{gg (eng. document?). De har som
tidigare ett huvud (textstat) och en kropp. Huvudet ser ut som innan
(n{stan), medan kroppen byts ut mot en array av { contentstype, string
}. I texthuvudet byts textl{ngden ut mot en array av { contentstype,
length }. F{ltet no_of_lines tas bort helt.
Contentstype {r en enum som anger vilken typ av data som str{ngen
inneh}ller, t ex text, bilder, musik, osv. De v{rden som denna enum
kan anta best{ms centralt av LysKOM-gruppen (dvs oss). Om n}gon vill
ha en egen sort f|r att experimentera med, kan de beg{ra en s}dan av
oss. N{r de kommer och s{ger "den h{r typen av data {r kul - vill ni
ha den?" kan vi best{mma om vi vill g|ra den officiell.
De v{rden som finns initialt {r f|ljande:
0 binary Anv{nds n{r inget annat passar
1 iso8859_1 Text lagrad enligt iso8859_1
2 iso8859_1_fill Dito, men klienten f}r l{gga in
newline d{r den vill f|r att bryta
rader.
3 rfc_header Kan anv{ndas f|r inkommande rfc-mail
F|r att avg|ra vad som {r {renderad, kan f|ljande regel anv{ndas:
Omm 1:a dataf{ltet {r av typen iso9959_1 eller
iso8859_1_fill, s} best}r {renderaden av texten
fram till f|rsta \n i detta f{lt.
Protokollet
I protokollet ing}r f|ljande objekt av f|ljande typer:
o Tal Ett icke-negativt decimalt heltal.
o Struct En samling objekt. Syntax:
{ obj1 obj2 obj3 ... objn }
o Str{ng En radda av oktetter. Syntax:
$nnnHxyzzy
o Array Noll, ett eller flera objekt av samma typ. Kan
inneh}lla upprepningar och/eller intervall. Syntax:
[ antal obj1 obj2 obj3 ... objn ]
o Upprepning Anv{nds inuti arrayer f|r att markera att ett visst
objekt upprepas ett antal g}nger. Syntax:
*antal objekt (Mellanslag mellan antal och objekt)
o Intervall Anv{nds f|r att ange en konsekutiv f|ljd av heltal
inuti en array. Syntax:
<f|rsta sista>
Mellanslag runt specialtecknen {, }, [, ], < och > {r frivilliga.
Bitstr{ngar {r bara ett specialfall av structar. De skickas allts}
som { 1 0 0 1 0 }.
Om det kommer fler f{lt i en struct {n vad man v{ntat sig, hoppar man
bara |ver dessa f{lt. T{nk dock p} att det kan f|rekomma nya
structar, arrayer och str{ngar inuti en struct.
Kommunikation med andra media
F|r att m|jligg|ra utbyte av inl{gg mellan LysKOM och andra media, t
ex email, Usenet News, vfsh, inf|rs n}gra nya misc-items. Dessa {r
f|ljande: x-author, x-creation-time, x-recpt, x-cc-recpt, x-sent-by
och x-sent-at, d{r x st}r f|r external. X-author, x-recpt, x-cc-recpt
och x-sent-by {r str{ngar, medan x-creation-time och x-sent-at {r
struct tm med tidszon adderad.
Dessa f{lt finns ungef{r s} h{r:
x-author Inleder en egen grupp. M}ste f|ljas omedelbart av en
x-creation-time. Endast en dylik grupp per inl{gg.
x-recpt Noll, ett eller flera s}dana h{r kan f|lja efter ett
local-no. De
----------------------------------------------------------------------
Remote Variables
RV {r en helt ny (tror jag) ide. RV {r en klass av protokoll som kan
implementeras ovanp} klassen RPC. Det g}r ut p} att varje RPC-anrop {r
en ARRAY (ASN.1 SEQUENCE OF) d{r varje element {r endera en
tilldelning (Assignment) eller referens (Reference). Varje anrop
resulterar i ett svar (det {r ju RPC), som ocks} {r en ARRAY med lika
m}nga element i motsvarande ordning.
En Assignment resulterar i OK eller Error, beroende p} om variabeln
fanns, om vi fick skriva den, etc. En Reference resulterar i ett OK
och variabelns v{rde, eller Error. Med Error f|ljer alltid errno och
kanske mer info, som i protokoll A.
Ibland vill man inte n|ja sig med Assignment. Man kan vilja ha += och
-= (&=, |= f|r BITSTRING).
Det kanske inte {r l{mpligt med RV |verallt? Det r{cker ju med att
*ett* av RPC-anropen k|r RV.
----------------------------------------------------------------------
ceder:
det blir t{ta ]tkomstkollar (p} varje RV)
en anv{ndare kan skicka en RPC med m}nga RV och l{gga beslag p}
servern
stort tillf{lligt allokerat minne i servern.
----------------------------------------------------------------------
Man kan identifiera klasserna
pers
conf
text
sess
med alla kan man g|ra create, delete
deras nummer verkar som parameter till andra v{rden (sina attribut)
eller som dubbelparameter till t.ex. membership eller mottagare
----------------------------------------------------------------------
SESSION
broadcast textnummer som skall skickas : Text-No
Who-Info (Session {r parameter) person : Pers-No
Who-Info (Session {r parameter) what-am-i-doing : HOLLERITH
Who-Info (Session {r parameter) working-conference : Conf-No
who-is-on : ARRAY Session
l{ses - session blir en slags local-pers-no
login kan bli create-session... Hmmm...
change-what-i-am-doing str{ngen : HOLLERITH
enable (Session {r underf|rst}dd) ena-level : INTEGER
logout : void
en liten void variabel som skrives
(eller avl{sning av sessionstid?)
pepsi : Conf-No
login (Pers-No {r parameter, session {r underf|rst}dd) password : HOLLERITH
skrives
logout : VOID
skrives
----------------------------------------------------------------------
PERSON
Person (Pers-No {r parameter) username : HOLLERITH
Person (Pers-No {r parameter) privileges : Priv-Bits
Person (Pers-No {r parameter) flags : Personal-Flags
Person (Pers-No {r parameter) last-login : Time-Date
Person (Pers-No {r parameter) user-area : Text-No
Person (Pers-No {r parameter) total-time-present : INTEGER
Person (Pers-No {r parameter) sessions : INTEGER
Person (Pers-No {r parameter) created-lines : INTEGER
Person (Pers-No {r parameter) created-bytes : INTEGER
Person (Pers-No {r parameter) read-texts : INTEGER
Person (Pers-No {r parameter) no-of-text-fetches : INTEGER
Person (Pers-No {r parameter) created-persons : INTEGER
Person (Pers-No {r parameter) created-confs : INTEGER
Person (Pers-No {r parameter) first-created-local-no : INTEGER
Person (Pers-No {r parameter) no-of-created-texts : INTEGER
Person (Pers-No {r parameter) no-of-marks : INTEGER
Person (Pers-No {r parameter) no-of-confs : INTEGER
create-pers nummer som har skapats : Pers-No
Man l{ser helt enkelt av detta elektriska v{rde
create-person (Pers-No {r parameter) name : HOLLERITH
create-person (Pers-No {r parameter) password : HOLLERITH
get-created-texts (person : Pers-No;
first : Local-Text-No;
no-of-texts : INTEGER; {r parameter) : Text-List
set-passwd (Pers-No; my-old-password : HOLLERITH
{r parameter) new-password : HOLLERITH
set-priv-bits (Pers-No {r parameter) : Priv-Bits
----------------------------------------------------------------------
CONFERENCE
set-garb-nice (Conf-No {r parameter) : Garb-Nice
set-permitted-submitters (Conf-No {r parameter) : Conf-No
set-presentation (Conf-No {r parameter) : Text-No
set-super-conf (Conf-No {r parameter) : Conf-No
set-supervisor (Conf-No {r parameter) : Conf-No
set-unread (Conf-No {r parameter) : INTEGER
Man kunde ju ha Conf+Pers {r parameter...
set-etc-motd (Conf-No {r parameter) : Text-No
lookup-name (conf-name : HOLLERITH {r parameter) : Conf-List
eller bara en ARRAY Conf-No ?
get-map (conference : Conf-No;
first : Local-Text-No;
no-of-texts : INTEGER {r parameter ) : Text-List
create-conf confnummer som har skapats : Conf-No
delete-conf confnummer som skall raderas : Conf-No
Conference (Conf-No {r parameter) name : HOLLERITH
Conference (Conf-No {r parameter) type : Conf-Type
Conference (Conf-No {r parameter) creation-time : Time-Date
Conference (Conf-No {r parameter) last-written : Time-Date
Conference (Conf-No {r parameter) creator : Pers-No
Conference (Conf-No {r parameter) presentation : Text-No
Conference (Conf-No {r parameter) supervisor : Conf-No
Conference (Conf-No {r parameter) permitted-submitters : Conf-No
Conference (Conf-No {r parameter) super-conf : Conf-No
Conference (Conf-No {r parameter) msg-of-day : Text-No
Conference (Conf-No {r parameter) nice : Garb-Nice
Conference (Conf-No {r parameter) no-of-members : INTEGER
Conference (Conf-No {r parameter) first-local-no : Local-Text-No
Conference (Conf-No {r parameter) no-of-texts : INTEGER
----------------------------------------------------------------------
TEXT
add-misc-info (Text-No {r parameter) : Misc-Info
sub-misc-info (Text-No {r parameter) : Misc-Info
get-misc-info (Text-No {r parameter) : ARRAY Misc-Info
get-misc-info (Text-No, Misc-Type {r parameter) : ARRAY Misc-Datum
Kanske text-conference?
get-text (text : Text-No;
start-char : INTEGER;
end-char : INTEGER {r parameter ) : HOLLERITH;
create-text nummer som har skapats : Text-No
delete-text textnummer som skall raderas : Text-No
Man skriver detta elektriska v{rde
Text-Stat (Text-No {r parameter) author : Pers-No
Text-Stat (Text-No {r parameter) creation-time : Time-Date
Text-Stat (Text-No {r parameter) no-of-links : INTEGER
Text-Stat (Text-No {r parameter) no-of-marks : INTEGER
Text-Stat (Text-No {r parameter) misc-info : ARRAY Misc-Info
create-text (Text-No {r parameter) text : HOLLERITH
create-text (Text-No {r parameter) misc-info : ARRAY Misc-Info
----------------------------------------------------------------------
TEXT-TEXT
add-comment { comment : Text-No; original : Text-No; }
add-footnote : { footnote : Text-No; original : Text-No; }
sub-comment (comment : Text-No; original : Text-No {r parameter ) : VOID
sub-footnote (footnote : Text-No; original : Text-No {r parametrar) : VOID
----------------------------------------------------------------------
SERVER
shutdown exit-val : INTEGER
skrives
get-info version : INTEGER;
get-info conf-pres-conf : Conf-No;
get-info pers-pres-conf : Conf-No;
get-info motd-conf : Conf-No;
get-info kom-news-conf : Conf-No;
get-info motd-of-lyskom : Text-No;
set-motd-lyskom : Text-No
skrives
get-time (delas? Obs! synkproblem) : Time-Date
sync : void
liten void som skrives
----------------------------------------------------------------------
PERSON-CONFERENCE
sub-member (conference : Conf-No; person : Pers-No) : VOID
add-member : { conference : Conf-No; new-member : Pers-No; }
|msesidiga. Variablerna kan inte bindas }t endera h}llet...
add-member priority : INTEGER;
add-member where : INTEGER;
conf & pers blir parametrar.
Membership (Pers-No och Conf-No {r parameter) last-time-read : Time-Date
Membership (Pers-No och Conf-No {r parameter) priority : INTEGER
Membership (Pers-No och Conf-No {r parameter) last-text-read : Local-Text-No
Membership (Pers-No och Conf-No {r parameter) read-texts : ARRAY Local-Text-No
?
get-members-params (conference : Conf-No;
first : INTEGER;
no-of-members : INTEGER {r parameter) : Member-List
get-membership-params (person : Pers-No;
first : INTEGER;
no-of-confs : INTEGER;
mask : BITSTRING {want-read-texts} {r parameter) : Membership-List
----------------------------------------------------------------------
CONFERENCE-TEXT
add-recipient (Text-No {r parameter) : Misc-Info
sub-recipient (text : Text-No; conference : Conf-No) : VOID
?asymmetri?
----------------------------------------------------------------------
PERSON-TEXT
get-marks (kan delas?) : Mark-List
Mark (Text-No; type : INTEGER {r parameter ) : VOID
??
mark-as-read (Conf-No; texts : ARRAY Local-Text-No {r parameter) : VOID
?? Egentligen en loop -- ge mig forth
mark-text (Text-No {r parameter) mark-type : INTEGER
kan vara snyggt... kan l{sas/skrivas (?) ORas ANDas?
----------------------------------------------------------------------
13 76 345 3 { 4711 4701 } 345 3 { 74 75 76 }
(60 + 43 = 103)
13 75 6 { 4711 74 4701 74 4711 75 4701 75 4711 76 4701 76 }
=13 6 { =99 =0000 %54 36 %54 36 =76 =1001 }
(26 + 179 = 205)
13 13 74 14 13 75 15 13 76
=13 99999999999999999999999999999999999999999999999999999999999999999999999999999999
%14 54 36
=15 99999999999999999999999999999999999999999999999999999999999999999999999999999999
doc/ideer/versioner deleted 100644 → 0
View file @ a07f6fcd
Filen 2kom/doc/versioner
14 oktober 1990
Aronsson was here
LysKOM Projektet
--------------------------------
Hantering av {ndringsf|rslag och versioner
--------------------------------
av Lars Aronsson
<Aronsson@Lysator.LiU.SE>
LysKOM
LysKOM {r ett datakonferenssystem. Andra liknande system {r QZ-KOM och
PortaCOM. LysKOM {r Copyright (C) 1990, 1991, 1992, 1993, 1994
datorf|reningen Lysator vid Universitetet och Tekniska H|gskolan i
Link|ping. Var och en till}ts fritt kopiera, {ndra och distribuera
LysKOM dokument och program, givet att mottagarna ges samma
r{ttigheter. Varken Lysator eller dess medlemmar tar n}got som helst
ansvar f|r dokumentens eller programmens riktighet eller f|ljderna av
deras anv{ndande.
Den h{r texten
Den h{r texten {r avsedd f|r internt bruk i Lysators LysKOM-projekt,
den {r inte avsedd f|r spridning. Detta hindrar inte att den kan
till{mpas i andra, liknande projekt.
Texten beskriver hur {ndringsf|rslag och bugrapporter tas emot, hur
specifikationer uppr{ttas f|r nya versioner (av programvara och
dokument) samt hur dessa specifikationer implementeras.
Kontinuerlig utveckling
LysKOM {r en produkt under kontinuerlig utveckling. LysKOM kommer
aldrig att bli f{rdigt, det kommer alltid (s} l{nge LysKOM anv{nds)
att beh|vas nya versioner. Detta placerar LysKOM i samma kategori av
produkter som operativsystem eller personbilar (varje }r en ny
}rsmodell av samma bil).
Det andra s{ttet att utveckla programvara {r det som l{rs ut i skolans
kurser. D{r samlas ett projekt runt en kravspecifikation, utvecklar
systematiskt och l{mnar ifr}n sig en f{rdig produkt som p} sin h|jd
beh|ver lite bugfixar i efterhand.
Skillnaden mellan skolmodellen och kontinuerlig utveckling {r att i
det senare fallet kommer en uppdaterad kravspecifikation (ofta
underf|rst}dd som en massa bugrapporter eller "ideer") innan den
f|rsta {r implementerad. Detta framkallar l{tt stress -- hur skall man
hinna hacka in alla nya {ndringar? Och med stressen f|ljer missmodet
och tr|ttheten.
L|sningen f|r att undvika den stressen {r att h}lla huvudet kallt och
inte inf|ra alla f|reslagna {ndringar. I st{llet planerar man vissa
versioner eller utg}vor av programvaran. Varje version ges en skriven
kravspecifikation d{r en lagom protion av inkommna {ndringsf|rslag tas
med. D{refter implementeras kravspecifikationen enligt den vanliga
skolmodellen. Versionen avslutas (f|rklaras f{rdig och s{tts i drift)
innan kravspecifikationen f|r n{sta version f}r tas fram.
Bugfilen
Med bugrapporter avses h{r rapporter om uppt{ckta fel, f|rslag till
{ndringar av funktioner samt allm{nna ideer om framtida utveckling.
Jag ser ingen anledning att skilja p} desssa kategorier.
Med program av typen LysKOM kommer anv{ndarna med bugrapporter utan
att man ber om det. Dessutom kommer man som utvecklare naturligtvis
ocks} med egna f|rslag. F|r att inte drunkna i alla rapporter m}ste
man ta hand om dem systematiskt. Ett s{tt {r att tillhandah}lla en
speciell blankett, som IDA gjorde i de gamla skrivarrummen. Ett annat
{r att h}lla en mailadress dit man kan skicka sina rapporter. I KOM
verkar det naturligt att h}lla ett m|te f|r detta {ndam}l. Men d}
m}ste ocks} n}gon regelbundet l{sa detta m|te och spara alla
rapporter.
Alla bugrapporter som kommer in skall ges ett l|pnummer och sparas i
en s.k. bugfil. Eftersom det inte alltid {r klart vilken del av
programmet som skall {ndras f|r att }tg{rda en viss bugrapport, h}lls
bara en bugfil f|r hela projektet. Uppdateringen av bugfilen sker
alltid parallellt med andra aktiviteter. N}gon b|r vara ansvarig f|r
uppdateringen, men filen tillh|r {nd} projektet, inte de medlemmar som
f|r tillf{llet deltar i det.
Ny version
En ny version av LysKOM (eller av n}gon del, t.ex. en klient eller ett
protokoll) b|rjar med att n}gon eller n}gra personer f}r lust att
arbeta. De v{ljer d} ur bugfilen n}gra rapporter de tycker {r viktiga
att }tg{rda. Inte fler {n att de tror sig klara av p} {ndlig tid, men
inte heller f|r f}. De tar sig ocks} ett nytt versionsnummer (eller
versionsbokstav f|r LysKOM protokoll).
Nu {r versionen ig}ng och ingen annan version av samma program f}r
p}b|rjas innan denna {r klar. Varken av samma grupp eller av n}gon
annan. En version kan dock n{r som helst l{ggas ner om
gruppmedlemmarna {r |verens om att de {r p} fel sp}r.
De bugrapporter som gruppen valt att }tg{rda markeras med
versionsnumret i bugfilen. Rapporterna f}r dock ligga kvar i filen