Den 3. stemme - en undersøgelse af skønlitterære ... - Kjeld Schmidt

6.2 Implementeringsmuligheder 95
6.2 Implementeringsmuligheder
Der er mange interessante teknologiske spørgsm˚al, der skal svares p˚a i forbindelse
med implementering af et computerbaseret samarbejdsværktøj. Implementering af
CONCERT har ikke været en del af vores m˚alsætning, men vi vil alligevel nævne
nogle væsentlige problematikker, vi forudser for implementering af systemet. En
af disse vil vi herefter beskrive ved hjælp af udvalgte XML-teknologier.
Det skal bemærkes, at vi i designet af CONCERT har valgt at se bort fra funktionaliteter
til kalender og tekstbehandling, som de f.eks. kan findes i Lotus Notes
og Microsoft Word. Disse funktionaliteter skal selvfølgelig bygges ind i systemet
ved implementering, ligesom muligheder for at arbejde off-line skal tænkes
ind i CONCERT. At vi har udelukket disse aspekter skyldes at vi har ønsket at
koncentrere os om de aspekter, som er særegne for det skønlitterære omr˚ade.
Atul Prakash har i artiklen Group Editors (Prakash, 1999) p˚apeget problemomr˚ader,
som er nødvendige at forholde sig til i det endelige design af ethvert
samarbejdssystem:
Concurrency control og l˚asning: Concurrency control er nødvendigt for at sikre
konsistens, n˚ar data editeres parallelt. Der kan nemt opst˚a problemer med
tabt data, n˚ar to brugere prøver at gemme et dokument p˚a samme tid. Den
første brugers ændringer ville forsvinde, hvis ikke der er tages højde for
dette problem i systemet. En mulig løsning kan være, at brugere kan ’l˚ase’
elementer, s˚aledes at andre ikke har skriverettigheder til dem, men fordi
mere end én forfatter skal kunne skrive samtidigt p˚a ét dokument i CON-
CERT, bør concurrency control-problemet løses ved en realisering af systemet.
Fejl-tolerance og god responstid: Et computerbaseret samarbejdsværktøj skal
kunne h˚andtere fejl i s˚avel hardware som i software b˚ade hvad ang˚ar fejl
p˚a de enkelte maskiner, der gør brug af systemet, og p˚a serveren systemet
ligger p˚a. Hvis en af computerne bryder sammen, skal systemet kunne reagere,
s˚aledes at risikoen for tab af data minimeres. Men p˚a samme tid skal
alle relevante processer, der er i gang p˚a det p˚agældende tidspunkt enten
fuldføres eller afbrydes og l˚ases.
Multi-bruger undo/redo: N˚ar flere arbejder p˚a det samme system — eller ligefrem
det samme dokument p˚a systemet — skal alle kunne undo’e sin egen
proces, og ikke bare den seneste handling udført p˚a dokumentet. Dette betyder,
at systemet skal kunne holde styr p˚a alle brugeres aktiviteter og gemme