Microcosm

From Arnoldsen

Current revision as of 13:42, 17 March 2008

Noget af ideen i Microcosm er at systemet skal integreres i så høj en grad som muligt i de applikationer der indgår, samtidigt med at der skal være de muligheder som man forventer at et udviklet hypermedie system har. Det er ikke umiddelbart let at gøre i alle applikationer, men microcosm har udviklet forskellige strategier. De har også forsøgt at udvikle interface til så mange forskellige 3. parts applikationer som muligt.

Microcosm er startet ved universitetet i South Hampton, men er gået hen og blevet et kommercielt produkt, og har været på markedet i mange år. Frank nævner i forelæsningen fra sidste år, at det stadig kan fås, men jeg har ikke kunnet finde forhandlere af det, og den logiske hjemmeside for produktet www.microcosm.com har jeg ikke kunnet få til at virke. Det har været oprettet, for der er en IP adresse tilknyttet, og google har stadig opslag til den. Den anden logiske mulighed www.microcosm.co.uk handler med en anden type produkter, og angiver ikke at de har handlet med dette.

Man har i Microcosm også forsøgt at lægge sig så tæt op ad dexter modellen som muligt Slet ikke i samme grad som DHM, så oplysninger om links og komponenter ligger i en separat database, og systemet er lavet, så denne database kan deles mellem flere brugere, så man på den måde opnår den styrke som vidensdeling har.

Den generelle model de arbejder efter, for at tilføje linkservice til 3. parts applikations-programmer er, at brugeren udvælger noget i applikationsprogrammet, kommunikerer det til frameworket, der håndterer forespørgslen i forhold til en filter-chain, der ligger i en database, og ud fra det finder den linkoplysning som frameworket skal håndtere, og f.x. starter en anden 3. parts applikation, med et dokument og en henvisning til hvor i dokumentet ankerpunktet befinder sig.

I artiklen om Microcosm [1] opstiller de 6 forskellige strategier for hvordan man kan integrere et framework til et hypermedie system:

• Skræddersyede viewere. Det er i de tilfælde, hvor applikationen i forvejen bare er en viewer, som en browser til internettet - der kan man skrive en helt ny browser. De har ikke brugt denne strategi.
• Rettelser direkte i sourcekoden til det eksisterende system. Det kan lade sig gøre til open source applikationer, som f.x. dem der er skrevet under GNU general public licence. De omtaler ikke denne mulighed, men den kunne fint ligge i deres måde at gøre tingene på. Det har dog den ulempe, at man hele tiden skal vedligeholde sin kode, når der kommer nye versioner. Det har til gengæld den fordel, at man helt kan styre hvordan man implementerer links, og kan programmere dem ind i bruger-grænsefladen.
• Objekt-orienteret genbrug. Det er hvis man kan skrive skræddersyet software ind i en eksisterende applikation, uden at de nødvendigvis har hele softwaren, men de kan komme til at integrere en komponent ind i applikationen, så deres system lægger sig ind, enten i stedet for, eller som supplement til den eksisterende software. Det ligner ikke deres strategi at gøre det på den måde.
• Tilføjelse ved hjælp af applikationens interface. Det kan være ved hjælp af f.x. et macro-programmerings-sprog, som dem man ser i office pakken, hvor man kan skrive mindre visual basic ting ind, som kan arbejde sammen med programmerne, eller en lisp-version som man ser det i AutoCAD. Det er deres foretrukne måde at gøre det på, ved de programmer der har den mulighed. Metoden arbejder sammen med programmets måde at markere objekter på, så man markerer det man ønsker at gøre til et link / følge linket fra, og så bruger man typisk en rullegardin-menu til at udføre den handling man ønsker.
• Et lille proxy-program der kan manipulere med de data der vises, så det eksisterende program forstår det. Proxy-programmet kommunikerer med frameworket for at kunne udføre handlingerne, og alt efter hvad der er muligt i programmet, så bruger det "snydekoder" til at navigere rundt i applikationen, det kan f.x. være noget i stil med at sende pile-indtastninger til programmet, for at få det til at reagere. Måden man kan få data ud af programmet er ved at udnytte clipboardet, der er standard i de fleste programmer.
• Start af programmet. Dette er den simplest reaktion, nemlig at hvis man følger et link til denne type applikation, så kan den starte applikationen med de ønskede data - ikke andet. Det betyder også, at det er svært at linke ud af sådan en applikation.

Microcosm implementerer alle de typer links jeg har beskrevet på nær det multiheadede link, og de forsøger, som det fremgår af deres strategier, at få deres framework til at fremstå som en integreret del af de applikationer de er i. Det gør de, hvis det kan lade sig gøre, ved at lægge en ekstra menu på, så brugeren ikke ser det som noget helt nyt der skal læres, men blot som en ekstra facilitet. I de tilfælde hvor de slet ikke kan "komme ind" i applikationen har de hægtet sig ind i styresystemet, så de lægger en ekstra funktionalitet ind oppe i titel-linien (den blå linie i windows), det er det de kalder en Universal Viewer.

Selvom de har linkene liggende eksternt, så er deres link retningsbestemte, der er en source og en destination. Som med alle andre hypermedie-systemer, der har eksterne links, er de sårbare over for ændringer i de dokumenter de linker til og fra. De har ikke nogen endelig løsning på det, fordi det er specielt fra program til program, men der hvor det er tekst-baserede dokumenter, så kan de gøre et forsøg på at genfinde linket, fordi de også gemmer tekstindholdet i ankerpunktet, men problemet ligger i, at de i de fleste tilfælde gemmer ankerpunktet som et offset i filen, og det gør at links bliver mere skrøbelige.

1. Hugh C. Davis, Simon Knight & Wendy Hall. Light Hypermedia Link Services: A Study of Third Party Application Integration (1994)