NO336905B1 - Fremgangsmåte og system for å synkronisere fler-bruker revisjoner av et delt objekt - Google Patents

Abstract

Mange forskjellige brukere kan aksessere, revidere og oppdatere det samme delte objektet samtidig gjennom flere forskjellige transporter. Revisjoner av det delte objektet blir automatisk synkronisert slik at alle brukere kan se revisjonene av det delte objektet. Konfliktskapende revisjoner blir brakt i overensstemmelse og flettet inn i en gjeldende versjon av det delte objektet. En klient kan be om den gjeldende versjonen av det delte objektet fra et lager når den gjeldende versjonen av det delte objektet ikke er tilgjengelig fra lageret. Den gjeldende versjonen av det delte objektet blir synkronisert med klienten når lageret mottar den gjeldende versjonen av det delte objektet.

Description

Bakgrunn for oppfinnelsen

Fildelingsprogrammer lar flere forskjellige brukere dele informasjon mellom seg. Mange brukere kan aksessere den samme filen samtidig. Alle brukerne kan lese filen, men bare den første brukeren som aksesserer filen har redigeringsrettigheter. Andre brukere som aksesserer filen tillates ikke å redigere filen. Det å levere ut en "read-only" versjon av en fil til alle utenom én bruker er uhensiktsmessig for store delte filer. Dette er spesielt problematisk hvis brukere ønsker å jobbe på en delt fil mens de er offline. For eksempel kan andre brukere være utestengt fra filen i lang tid hvis den første brukeren som aksesserte den delte filen er ute på en forretningsreise.

EP 0907125 beskriver en løsning der en liste med sett av filer som trenger å bli brakt i overenstemmelse med hverandre (kollisjoner) blir automatisk lastet inn i en kollisjons håndterer. En bruker arbeider seg gjennom listen og løser forskjeller ved å velge en av filene, eller ved å flette de sammen ved valg og modifikasjoner som påkrevet. Brukeren er gitt taster som gir raske skift mellom forskjellige stiler for visning (splitte, splitte - flette, sammensatt fletting) som gir brukeren mulighet til å se filene på et antall ulike måter som videre forenkler prosessen.

Oppsummering av oppfinnelsen

Foreliggende oppfinnelse vedrører en fremgangsmåte og et system for å synkronisere flere brukeres revisjoner av et delt objekt. Objektet kan være en hvilken som helst entitet som kan deles, for eksempel en fil. Mange forskjellige brukere kan aksessere, revidere og oppdatere det samme delte objektet samtidig gjennom flere forskjellige transporter. Brukerne nektes ikke å aksessere og revidere et delt objekt når en annen bruker har aksess til det delte objektet. Alle bemyndigede brukere kan revidere det delte objektet samtidig. Brukere er ikke nødt til å være koblet til det delte objektet mens de foretar revisjoner. Revisjonene kan bli gjort offline på en lokalt bufret versjon av objektet. Revisjonene blir da synkronisert med andre brukeres revisjoner når det delte objektet er tilgjengelig. Revisjoner av det delte objektet blir automatisk synkronisert, slik at alle brukere kan se revisjonene av det delte objektet. Forskjellige brukere kan revidere det delte objektet på forskjellige tidspunkter, slik at flere versjoner av det delte objektet kan eksistere side om side. Den nyeste versjonen av det delte objektet er den versjonen som omfatter de siste synkroniserte revisjonene som er tilgjengelige for andre bemyndigede brukere.

En konflikt kan oppstå når to brukere reviderer samme del av det delte objektet. Den reviderte delen kan ikke bli synkronisert med det delte objektet dersom den er i konflikt med en annen brukers revisjon av samme del. Den delen av det delte objektet som inneholder den konfliktskapende revisjonen blir vist på en konfliktside. Konfliktsiden er lik en motsvarende master-side i den nyeste versjonen av den delte filen, bortsett fra at den delen av det delte objektet som inneholder den konfliktskapende revisjonen er fremhevet og vist i stedet for den synkroniserte revisjonen. En konfliktindikator vises på master-siden i det delte objektet. Konfliktsiden blir vist ved siden av master-siden når konfliktindikatoren velges. Brukeren blir vist både den synkroniserte tilstanden i master-siden og den motsvarende konfliktsiden. Brukeren kan avstemme og integrere de konfliktskapende revisjonene i master-siden. Konfliktskapende revisjoner som identifiseres som irrelevante kan bli kastet.

I ett aspekt ved oppfinnelsen mottas en revisjon av et delt objekt. Det bestemmes hvorvidt revisjonen er i konflikt med en synkronisert revisjon på en

master-side i det delte objektet. Revisjonen blir synkronisert med det delte objektet når revisjonen bestemmes å vedrøre en gjeldende versjon av det delte objektet, og når revisjonen bestemmes å ikke være i konflikt med en synkronisert revisjon.

Foreliggende oppfinnelse er særlig egent til å tilveiebringe et system som utfører en tilhørende fremgangsmåte for å synkronisere flere brukerrevisjoner av et delt objekt, omfattende det å: motta en revisjon av det delte objektet, aksessere det delte objektet på en server for å danne en asynkron server kommunikasjons modus mellom en klient og serveren; bestemme stedet til en spesifikasjons fil assosiert med det delte objektet basert på et unikt sted identifisert i det aksesserte objektet; hente spesifikasjonsfilen på klienten basert på den unike stedsidentifikator i det aksesserte delte objektet, hvor spesifikasjonsfilen identifiserer stedet hvor andre forskjellige versjoner av det delte objektet er lagret; basert på den hentede spesifikasjonsfilen å gå over, på en automatisk og sømløs måte, fra den asynkrone server kommunikasjonen til en likemanns kommunikasjons modus ved å etablere et likemanns-til-likemanns nettverk med andre klienter som aksesserer en versjon av det delte objektet identifisert av spesifikasjonsfilen; motta en revisjon av det delte objektet på klienten der revisjonen er assosiert med en global unik identifikator, GUID; og et tidsstempel, der tidsstempelet identifiserer tidspunktet revisjonen var laget på; bestemme, basert på tidsstempelet og GUID, om revisjonen er tilgjengelig fra likemanns-til-likemanns nettverket; og dersom revisjonen ikke er tilgjengelig fra likemanns-til-likemannsnettverket, å sende revisjonen til likemanns-til-likemanns nettverket.

Kort beskrivelse av figurene

Figur 1 illustrerer en databehandlingsanordning som kan anvendes i et eksempel på utførelse av foreliggende oppfinnelse. Figur 2 er et blokkdiagram som illustrerer et system for å synkronisere flere brukeres revisjoner av et delt objekt, ifølge foreliggende oppfinnelse. Figur 3 er et hierarkisk diagram som illustrerer koblede noder som representerer forskjellige deler av et delt objekt, ifølge foreliggende oppfinnelse. Figur 4 illustrerer en master-side i et delt objekt og en motsvarende konfliktside, ifølge foreliggende oppfinnelse. Figur 5 er et blokkdiagram som illustrerer et system for å synkronisere flere brukeres revisjoner av et delt objekt, ifølge foreliggende oppfinnelse. Figur 6 er et flytdiagram som illustrerer en fremgangsmåte for å synkronisere flere brukeres revisjoner av et delt objekt, ifølge foreliggende oppfinnelse. Figur 7 er et flytdiagram som illustrerer en fremgangsmåte for å avstemme og integrere konfliktskapende revisjoner fra flere brukere i et delt objekt, ifølge

foreliggende oppfinnelse.

Figur 8 er et flytdiagram som illustrerer en fremgangsmåte for å synkronisere flere brukeres revisjoner av et delt objekt, ifølge foreliggende oppfinnelse. Figur 9 er et flytdiagram som illustrerer en fremgangsmåte for sømløst å skifte fra asynkron til synkron kommunikasjonsmodus, ifølge foreliggende oppfinnelse. Figur 10 er et flytdiagram som illustrerer en fremgangsmåte for sømløst å skifte fra synkron til asynkron kommunikasjonsmodus, ifølge foreliggende oppfinnelse.

Detaljert beskrivelse av den foretrukne utførelsesform Foreliggende oppfinnelse vedrører en fremgangsmåte og et system for å synkronisere flere brukeres revisjoner av et delt objekt. Objektet kan være en hvilken som helst entitet som kan deles, for eksempel en fil. Mange forskjellige brukere kan aksessere, revidere og oppdatere det samme delte objektet samtidig gjennom flere forskjellige transporter. Brukerne nektes ikke å aksessere og revidere et delt objekt når en annen bruker har aksess til det delte objektet. Alle bemyndigede brukere kan revidere det delte objektet samtidig. Brukere er ikke nødt til å være koblet til det delte objektet mens de gjør revisjoner. Revisjonene kan bli gjort offline på en lokalt bufret versjon av objektet. Revisjonene blir da synkronisert med andre brukeres revisjoner når det delte objektet er tilgjengelig. Revisjoner av den delte filen blir automatisk synkronisert, slik at alle brukere kan se revisjonene av det delte objektet. Forskjellige brukere kan revidere det delte objektet på forskjellige tidspunkter, slik at flere versjoner av det delte objektet kan eksistere side om side. Den nyeste versjonen av det delte objektet er den versjonen som omfatter de sist synkroniserte revisjonene som er tilgjengelige for andre bemyndigede brukere.

En konflikt kan oppstå når to brukere reviderer samme del av det delte objektet. Den reviderte delen kan ikke bli synkronisert med det delte objektet dersom den er i konflikt med en annen brukers revisjon av den samme delen. Den delen av det delte objektet som inneholder den konfliktskapende revisjonen blir vist på en konfliktside. Konfliktsiden er lik en motsvarende master-side av den nyeste versjonen av den delte filen, bortsett fra at den delen av det delte objektet som inneholder den konfliktskapende revisjonen er fremhevet og vist i stedet for den synkroniserte revisjonen. En konfliktindikator vises på master-siden i det delte objektet. Konfliktsiden blir ved siden av master-siden når konfliktindikatoren velges. Brukeren blir vist både den synkroniserte tilstanden til master-siden og den motsvarende konfliktsiden. Brukeren kan avstemme og flette inn de konfliktskapende revisjonene i master-siden. Konfliktskapende revisjoner som identifiseres som irrelevante kan bli kastet.

Eksempel på kiøremiliø

Med henvisning til figur 1 omfatter ett eksempel på system for å realisere oppfinnelsen en databehandlingsanordning, så som databehandlingsanordningen 100. Databehandlingsanordningen 100 kan være en klient, en tjener, en mobil anordning eller en hvilken som helst annen databehandlingsanordning som vekselvirker med data i et nettverksbasert samarbeidssystem. I en helt grunnleggende oppbygning omfatter databehandlingsanordningen 100 typisk minst én prosesseringsenhet 102 og systemminne 104. Avhengig av den eksakte oppbygningen og typen databehandlingsanordning kan systemminnet 104 være volatilt (for eksempel RAM), ikke-volatilt (for eksempel ROM, flash minne, etc.) eller en hvilken som helst kombinasjon av de to. Systemminnet 104 inneholder typisk et operativsystem 105, én eller flere applikasjoner 106, og kan inneholde pro-gramdata 107. En revisjonsynkroniseringsmodul 108, som er beskrevet nærmere nedenfor, er implementert i applikasjonene 106.

Databehandlingsanordningen 100 kan ha ytterligere trekk eller funksjonalitet. Foreksempel kan databehandlingsanordningen 100 også omfatte ytterligere datalagringsanordninger (flyttbare og/eller stasjonære) så som, for eksempel, magnetiske disker, optiske disker, eller bånd. Slike ytterligere lagre er illustrert i figur 1 av et flyttbart lager 109 og et stasjonært lager 110. Datalagringsmedier kan omfatte volatile og ikke-volatile, flyttbare og stasjonære medier realisert med en hvilken som helst metode eller teknologi for lagring av informasjon, så som datamaskin-lesbare instruksjoner, datastrukturer, programmoduler eller andre data. Systemminnet 104, det flyttbare lageret 109 og det stasjonære lageret 110 er alle eksempler på datalagringsmedier. Datalagringsmedier omfatter, men er ikke begrenset til, RAM, ROM, EEPROM, flash-minne eller annen minneteknologi, CD-ROM, DVD (Digital Versatile Disk) eller andre optiske lagre, magnetkassetter, magnetbånd, magnetplatelagre eller andre magnetiske lagringsanordninger, eller et hvilket som helst annet medium som kan anvendes for å lagre den ønskede informasjonen og som kan aksesseres av databehandlingsanordningen 100. Et hvilket som helst slikt datalagringsmedium kan være del av anordningen 100. Databehandlingsanordningen 100 kan også ha én eller flere innmatingsanordninger 112, så som et tastatur, en mus, en innmatingspenn, en talebasert innmatingsanordning, en berøringsbasert innmatingsanordning, etc. Én eller flere utmatingsanordninger 114, så som en fremvisningsan-ordning, høyttalere, en skriver, etc, kan også være innlemmet.

Databehandlingsanordningen 100 inneholder også kommunikasjonsfor-bindelser 116 som gjør det mulig for anordningen å kommunisere med andre databehandlingsanordninger 118, for eksempel over et nettverk. Nettverk omfatter lokale nettverk og regionale nettverk, så vel som andre storskala nettverk omfattende, men ikke begrenset til, intranett og ekstranett. Kommuni-kasjonsforbindelsen 116 er ett eksempel på kommunikasjonsmedium. Kommunikasjonsmedier kan typisk omfatte datamaskin-lesbare instruksjoner, datastrukturer, programmoduler eller andre data i et modulert datasignal, så som en bærerbølge eller en annen transportmekanisme, og omfatter et hvilket som helst informasjonsleveringsmedium. Med et "modulert datasignal" menes et signal som får én eller flere av sine egenskaper satt eller endret for det formål å kode inn informasjon i signalet. Som et

eksempel, og ikke en begrensning, omfatter kommunikasjonsmedier kablede medier så som et kabelnettverk eller en direktekoblet forbindelse, og trådløse medier så som akustiske, RF-baserte, infrarøde og andre trådløse medier. Betegnelsen datamaskin-lesbare medier, som den anvendes her, omfatter både lagringsmedier og kommunikasjonsmedier.

Synkronisering av flere brukeres revisjoner av en delt fil

Figur 2 er blokkdiagram som illustrerer et system for å synkronisere flere brukeres revisjoner av et delt objekt. Objektet kan være en hvilken som helst entitet som kan deles, for eksempel en fil. Systemet innbefatter klienter 200, 210, 220, 230, en epost-tjener med mulighet for fillagring, så som utvekslingstjeneren 240, en web-server 250, et peer-til-peer-nettverk 260 og et epost-vedlegg 270. Klientene 200, 210 er koblet til utvekslingstjeneren 240.

Klientene 210, 220 er koblet til web-serveren 250. Klientene 210, 220 er også sammenkoblet gjennom peer-til-peer-nettverket 260. Epost-vedlegget 270 er beregnet for å bli overført til og fra klienten 230 av web-serveren 250. Klientene 200, 210 tilhører begge samme bruker (Bruker 1). For eksempel aksesseres klient 200 av Bruker 1 hjemme, og klient 210 aksesseres av Bruker 1 på jobben. Klientene 220, 230 tilhører forskjellige brukere (henholdsvis Bruker 2 og Bruker 3). Klientene 200, 210, 220, 230 har hver sine respektive buffere 202, 212, 222, 232 for lokal lagring av et delt objekt. Peer-til-peer-nettverket 260 omfatter en virtuell tjener 262 for å overføre et delt objekt mellom klientene 210, 220. En revisjonsfil 242 og delte objekter 252, 264, 272 er henholdvis lagret i utvekslingstjeneren 240, web-serveren 250, den virtuelle tjeneren 262 og epost-vedlegget 270. Revisjonsfilen 242 og de delte objektene 252, 264, 272 kan ha en tilhørende peer-gruppeidentifikator. Gruppeidentifikatoren identifiserer brukerne som har tillatelse til å aksessere og revidere et gitt delt

objekt (dvs. peer-gruppen). I én utførelsesform er gruppeidentifikatoren en URL (Uniform Resource Locator) til peer-gruppen, som kan referere til en hvilken som helst web-klient. De delte objektene 252, 264 har respektive tilhørende spesifikasjonsfiler 254, 266.

Mange forskjellige brukere kan aksessere, redigere og oppdatere det samme delte objektet samtidig gjennom flere forskjellige transporter. For eksempel kan Bruker 1 ved klient 210 og Bruker 2 ved klient 220 aksessere det delte objektet 252 fra web-serveren 250. Det delte objektet er lagret lokalt i de respektive bufrene 212, 222. Både Bruker 1 og Bruker 2 kan revidere det delte objektet 252. Revisjonene blir synkronisert med det delte objektet 252 på web-serveren 250, slik at Bruker 1 kan se revisjonene gjort av Bruker 2 og Bruker 2 kan se revisjonene gjort av Bruker 1.

I et annet eksempel kan Bruker 3 dele tilgang til det delte objektet 272 med Bruker 2 gjennom epost-vedlegget 270. Bruker 2 kan revidere et lokalt lagret delt objekt og sende en e-postmelding til Bruker 3 med hele det delte objektet eller bare revisjonene av det delte objektet vedlagt. Revisjonene gjort av Bruker 2 blir synkronisert med det delte objektet 252 på web-serveren 250. Når e-posten mottas ved klienten 230, blir revisjonene gjort av Bruker 2 automatisk synkronisert med det lokale delte objektet lagret i bufferet 232. Bruker 3 kan da foreta ytterligere revisjoner av det delte objektet 272, og svare til Bruker 2 med hele det delte objektet eller bare revisjonene av det delte objektet innlemmet som epost-vedlegget 270. Revisjonene gjort av Bruker 3 blir synkronisert med det delte objektet 252 på web-serveren 250. Det delte objektet ved klient 220 blir også oppdatert til å omfatte revisjonene gjort av Bruker 3.

I et annet eksempel kan Bruker 1 aksessere et delt objekt enten hjemme på klient 200 eller på jobben på klient 210 via utvekslingstjeneren 240. Utvekslingstjenere anvendes ofte når aksess til en ekstern tjener ikke er tillatt eller ikke er mulig. Revisjonsfilen 242 omfatter revisjoner av det delte objektet. Revisjonsfilen 242 kan bli overført mellom klientene 200, 210 ved hjelp av en USB-(Universal

Serial Bus)-basert tilknytning, et epost-program eller en annen mekanisme som muliggjør overføring av revisjoner frem og tilbake. Revisjonene anvendes på klientene 200, 210, slik at det lokale delte objektet lagret i bufrene 202, 212 kan bli oppdatert.

Utvekslingstjeneren 240 kan ha en begrensning på filstørrelsen den kan håndtere (f.eks. maksimalt 2 megabyte). Bruker 1 kan laste opp revisjonsfilen 242, som omfatter eventuelle revisjoner av det delte objektet, fra klient 200 til utvekslingstjeneren 240. Revisjonsfilen 242 kan bli overført fra klient 200 til klient 210 i flere deler når revisjonsfilen 242 er større enn størrelsesbegrensningen til utvekslingstjeneren 240. Filprotokollen støtter en forespørsel/fyllingsprosess for overføring av fildelene. I én utførelsesform har utvekslingstjeneren 240 et tilhørende epost-program. Revisjoner gjort av en annen bruker (Bruker 2) kan bli overført fra klient 220 til klient 210 gjennom web-serveren 250 eller over peer-til-peer-nettverket 260, og deretter bli sendt til klient 200 via en epost-konto for Bruker 1. I en annen utførelsesform kan klienten 200 jevnlig spørre utvekslingstjeneren 240 om en gjeldende revisjonsfil.

I et annet eksempel kan peer-til-peer-nettverket 260 bli etablert mellom klientene 210, 220 når forbindelsen fra klientene 210, 220 til web-serveren 250 mistes eller når Bruker 1 og Bruker 2 foretrekker å kommunisere direkte og synkront i sanntid. Bruker 1 og Bruker 2 kan foretrekke å kommunisere over peer-til-peer-nettverket 260 fordi deling av objekter via web-serveren 250 kan resultere i en forsinkelse mellom når revisjoner blir gjort på klient 210 og når revisjonene er tilgjengelige ved klient 220. Forsinkelsen kan være en følge av høy trafikk på tjeneren. Peer-til-peer-nettverket 260 gjør det mulig å overføre revisjoner av det delte objektet direkte mellom klientene 210, 220, i stedet for gjennom web-serveren 250. I én ut-førelsesform er peer-til-peer-nettverket 260 et TCP/IP-nettverk . TCP/IP-nettverket muliggjør rask lagring og fremhenting av revisjoner.

Klientene 210, 220 kan hver ha en kopi av det delte objektet 252 lagret lokalt i buffrene 212, 222 når forbindelsen med web-serveren 250 blir avbrutt. Peer-gruppeidentifikatoren for det delte objektet 252 angir at både Bruker 1 og Bruker 2 aksesserer det delte objektet samtidig. Brukerne blir klar over hverandre når de begge aksesserer et opprettet peer-til-peer-nettverk (f.eks. kan begge brukerne jobbe på bærbare datamaskiner på samme fly). Peer-til-peer-nettverket 260 lar Bruker 1 og Bruker 2 samtidig aksessere revisjoner av det delte objektet 264 på den virtuelle tjeneren 262 og lage nye revisjoner. Revisjonene blir øyeblikkelig duplisert på klientene 210, 220, slik at Bruker 1 og Bruker 2 aktivt kan samarbeide på det delte objektet 264. Peer-til-peer-nettverket 260 kan bli deaktivert når Bruker 1 og Bruker 2 ikke lenger befinner seg i nærheten av hverandre (f.eks. når brukerne returnerer til sine respektive kontorer), eller når Bruker 1 og Bruker 2 ikke lenger ønsker å kommunisere i sanntid. Det delte objektet 252 kan da aksesseres fra web-serveren 250. Skiftet mellom å aksessere delte objektrevisjoner over peer-til-peer-nettverket 260 og web-serveren 250 er automatisk og sømløst.

Klientene 210, 220 kan motta gjeldende revisjoner fra både web-serveren 250 og peer-til-peer-nettverket 260. Hver revisjon som gjøres av det delte objektet blir tildelt en globalt unik identifikator (GUID) og et tidsstempel. Tidsstempelet angir når revisjonen ble gjort. Klient 210 kan modifisere det delte objektet 252 på web-serveren 250. Klient 220 avgjør om den lokale versjonen av det delte objektet i bufferet 222 er gyldig ved å sammenlikne en GUID og et tidsstempel for det bufrede objektet med GUID'en og tidsstempelet for det delte objektet 252 på web-serveren 250. Dersom den gjeldende versjonen ikke er lagret lokalt, blir de nyeste revisjonene som ikke er innlemmet i det bufrede objektet lastet ned fra web-serveren 250 til klienten 220 og synkronisert med den lokale filen. Følgelig trenger ikke hele det delte objektet bli lastet ned til klienten 220 hver gang den lokale versjonen av det delte objektet blir oppdatert.

I én utførelsesform kan klient 220 bestemme fra GUID'en og tidsstempelet for revisjonen at de samme endringene er tilgjengelige fra peer-til-peer-nettverket 260. Det blir da ikke gjort noe som helst siden klienten 220 allerede har innlemmet endingene. I en annen utførelsesform kan klient 220 bestemme fra GUID'en og tidsstempelet for revisjonen at de samme endringene ikke er tilgjengelige fra peer-til-peer-nettverket 260. Klient 220 sender derfor revisjonene til peer-til-peer-nettverket 260, slik at andre brukere koblet til peer-til-peer-nettverket 260 kan synkronisere med den gjeldende versjonen av det delte objektet.

Klienten 220 kan motta en annen revisjon fra peer-til-peer-nettverket 260. Det delte objektet i bufferet 222 blir oppdatert. Klienten 220 avgjør om den gjeldende tilstanden til det delte objektet også er tilgjengelig på web-serveren 250 ved anvendelse av GUID'en og tidstempelet for revisjonen. Dersom det delte objektet 252 på web-serveren 250 ikke er synkronisert med den gjeldende tilstanden til det delte dokumentet, sender klienten 220 den seneste revisjonen til web-serveren 250 slik at det delte objektet 252 kan bli oppdatert.

Asynkron kommunikasjon kan forekomme når en klient reviderer det delte objektet mens den er koblet til systemet gjennom en fysisk tjener. Begrensninger ved tjeneren kan gjøre at synkroniseringer av delte objekter er forsinket i forhold til når revisjonene blir utført av en bruker. I én utførelses-form kan klienten revidere en lokalt bufret versjon av det delte objektet mens den ikke er koblet til systemet. Hvilke som helst revisjoner gjort av klienten kan bli synkronisert med det delte

objektet når klienten igjen kobler seg til systemet gjennom en tjener. Klienten kan sømløst skifte mellom lokal aksess og synkron og asynkron kommunikasjon, slik at brukeren ikke er klar over at kommunikasjonsmåten er endret. En bruker kan flytte på seg, og alle tilgjengelige datadelingstransporter (f.eks. peer-til-peer-nettverk, tjenere) identifiseres automatisk. Brukeren kan således aksessere et delt

objekt og samarbeide med andre bemyndigede brukere gjennom forskjellige mekanismer.

Hvert delte objekt har en tilhørende spesifikasjonsfil. Spesifikasjonsfilen identifiserer lagringsstedene hvor andre versjoner og

instanser av det delte objektet er lagret innenfor systemet. I én utførelsesform er spesifikasjonsfilen en XML-(eXtensible Markup Language)-fil. I en annen ut-førelsesform identifiserer spesifikasjonsfilen flere delte objekter. I en annen ut-førelsesform kan spesifikasjonsfilen vedrøre et hvilket som helst objekt som kan deles mellom klienter. For eksempel kan spesifikasjonsfilen tilhøre et helt delt objekt eller en hvilken som helst del av det delte objektet (f.eks. en innholdscontainer, en seksjon, en side, et utdrag, etc).

Spesifikasjonsfilen kan være lagret hvor som helst innenfor systemet. Som vist i figuren er spesifikasjonsfilen 254 tilknyttet det delte objektet 252. Både det delte objektet 252 og spesifikasjonsfilen 254 er lagret på web-serveren 250.1 en annen utførelsesform lagres spesifikasjonsfilen i det delte objektet. I atter en annen utførelsesform lagres spesifikasjonsfilen i en aktiv katalog. I atter en annen utførelsesform lagres spesifikasjonsfilen flere steder innenfor systemet. Spesifikasjonsfilen lagres på et lagringssted som identifiseres av en unik stedsidentifikator. Den unike stedsidentifikatoren kan identifisere en filtjener, et delt område på en tjener, en web-server eller en peer-gruppe.

Det delte objektet kan aksesseres lokalt fra et hurtigbuffer, gjennom en tjener eller over et peer-til-peer-nettverk. Klienten henter frem spesifikasjonsfilen fra lagringsstedet identifisert av den unike identifikatoren i det motsvarende delte

objektet. I én utførelsesform kan klienten lagre spesifikasjonsfilen lokalt for fremtidig referanse. Spesifikasjonsfilen angir lagringsstedene for eventuelle andre versjoner og instanser av det delte objektet i systemet (f.eks. i et del-lager eller en peer-gruppe). Dersom en annen versjon/instans av det delte objektet er lagret i en peer-gruppe, kan spesifikasjonsfilen omfatte den tilhørende gruppeidentifikatoren.

I én utførelsesform aksesserer klienten 220 det delte objektet 252 på web-serveren 250. Klienten 220 blir automatisk koblet til andre klienter som også aksesserer det delte objektet 252 (f.eks. peer-gruppen). Klienten 220 henter frem spesifikasjonsfilen 254 for det delte objektet 252. Spesifikasjonsfilen 254 identifiserer lagringsstedene for forskjellige versjoner og instanser av det delte objektet 252. Følgelig kan klienten 220 etablere et peer-til-peer-nettverk med en hvilken som helst annen klient i peer-gruppen når en hvilken som helst klient i peer-gruppen aksesserer en versjon/instans av det delte objektet 252 identifisert av spesifikasjonsfilen 254. Klienten 220 kan da koble seg fra web-serveren 250 og fortsette å aksessere det delte objektet 252 over peer-til-peer-nettverket.

I en annen utførelsesform kan klienten 210 aksessere det delte objektet 264 fra peer-til-peer-nettverket 260. Klienten 210 henter frem spesifikasjonsfilen 266 for det delte objektet 264. Klienten 210 kan koble seg til en tjener og bestemme hvilke klienter som også er koblet til tjeneren. De tilkoblede klientene kan aksesseres gjennom tjeneren når peer-til-peer-nettverket 260 ikke er tilgjengelig. Det delte objektet 264 (eller 252) og den tilhørende spesifikasjonsfilen 264 (eller 254) lar klienten 210 (eller klienten 220) skifte automatisk og sømløst mellom asynkron og synkron kommunikasjonsmodus.

Brukere nektes ikke å aksessere og revidere et delt objekt når en annen bruker har aksess til det delte objektet. Alle bemyndigede brukere kan revidere det delte objektet samtidig. I én utførelsesform kan en kortvarig utestengelse være nødvendig for å sikre revisjonstransaksjonens integritet. For eksempel kan en bruker gjøre en omfattende revisjon av det delte dokumentet mens vedkommende ikke er koblet til tjeneren. Når brukeren igjen kobler seg til tjeneren, kan andre klienter for en kort periode bli nektet å aksessere det delte objektet inntil hele brukerens revisjon er integrert i det delte objektet.

Figur 3 er et hierarkisk diagram som illustrerer koblede noder som representerer forskjellige deler av et delt objekt. I én utførelsesform er det delte objektet en notisbok som deles mellom flere brukere. Notisbok-noden 300 symboliserer hele det delte objektet. Mappenoden 310 er omfattet innenfor notisbok-noden 300. Kapittelnoden 320 er omfattet innenfor mappenoden 310. Side-noder 330, 335 er omfattet innenfor kapittelnoden 310. Tabellnoden 340, fargenoden 342, utdragnoden 344 og bildenoden 346 er omfattet innenfor side-noden 330. Utdragelement-noden 350 er omfattet innenfor utdragnoden 344. Tekstnoden 360 er omfattet innenfor utdragelement-noden 350. Forskjellige noder kan grupperes sammen i en innholdscontainer. For eksempel kan utdragnoden 344, utdragelement-noden 350 og tekstnoden 360 bli gruppert sammen som innholdscontainer RO. Innholdscontaineren RO tildeles en GUID (f.eks. GUID-0). Denne identifikatoren identifiserer innholdscontaineren RO entydig.

En innholdscontainer omfatter innhold i et delt objekt (f.eks. et ord, en setning, et avsnitt, en side, en tabell, et bilde, håndskrift, en URL eller en hvilken som helst kombinasjon av data inneholdt i det delte objektet). Innholdscontainere gir en dimensjon for innhold i et objekt som er gruppert sammen. For eksempel kan en innholdscontainer svare til en linje, et avsnitt, en side eller bestemte elementer på en side (f.eks. bare tabellene på en gitt side).

Det delte objektet lagrer en første versjon av diagrammet. Spesifikke operasjoner kan deretter bli utført på individuelle innholdscontainere. For eksempel kan en bruker revidere dataene i en innholdscontainer. Revisjonen av det delte objektet kan bli identifisert som en tilstand for innholdscontaineren. Det delte

objektet lagrer de reviderte innholdscontainerene i diagrammet. En gjeldende tilstand for innholdscontaineren sammenliknes med en tidligere tilstand med bruk av GUID'er og tidsstempler, slik at det kan avgjøres om innholdscontaineren har blitt revidert.

For eksempel kan to forskjellige brukere begge aksessere det delte dokumentet og modifisere innholdscontaineren RO. Én bruker kan revidere innholdscontaineren RO ved å slette tekstnoden 360 (som vist i revisjon R1). Revisjon R1 blir lagret i det delte objektet. Revisjon R1 tildeles en GUID (f.eks. GUID-1) som entydig identifiserer den reviderte containeren, og et tidsstempel som angir tidspunktet og datoen når revisjon R1 ble skrevet til det delte objektet. En annen bruker kan revidere innholdscontaineren RO ved å legge til tekstnoden 380 i utdragelement-noden 350 (som vist i revisjon R2). Revisjon R2 blir lagret i det delte

objektet. Revisjon R2 tildeles et tidsstempel og en GUID (f.eks. GUID-2) som entydig identifiserer den reviderte innholdscontaineren.

Forskjellige brukere kan revidere et delt objekt på forskjellige tidspunkter, slik at flere versjoner av det delte objektet kan eksistere side om side. Det finnes imidlertid bare én nyeste versjon av det delte objektet. I én ut- førelsesform er den nyeste versjonen av det delte objektet den versjonen som omfatter de siste revisjonene som er synkronisert med det delte objektet og gjort tilgjengelige for andre bemyndigede brukere.

For eksempel kan en bruker revidere en innholdscontainer i et delt objekt som er identifisert som revisjon R1 ved å legge til utdragelement-noden 370 i utdragnoden 344 (som vist i revisjon R3). Revisjon R3 blir lagret i det delte objektet. Revisjon R3 tildeles også et tidsstempel og en GUID (f.eks. GUID-3) som entydig identifiserer den reviderte innholdscontaineren. Revisjon R3 er en utvidelse av revisjon R1. Følgelig er revisjon R1 den nyeste versjonen av det delte objektet som brukeren kjenner til (f.eks. den lokalt lagrede versjonen). Det delte objektet undersøkes med tanke på hvorvidt den nyeste versjonen av det delte objektet fortsatt er revisjon R1. I én utførelses-form kan den nyeste versjonen av det delte objektet bli identifisert ved sammenlikning av tidsstempler og GUID'er for forskjellige innholdscontainere. Dersom den nyeste versjonen av det delte objektet har et nyere tidsstempel enn revisjon R1, har da en annen bruker (f.eks. brukeren som laget revisjon R2) modifisert samme innholdscontainer på et senere tidspunkt.

Dersom en annen bruker har modifisert den samme innholdscontaineren siden revisjon R1 ble synkronisert med det delte objektet, kan ikke eventuelle revisjoner som er en utvidelse av revisjon R1 (f.eks. revisjon R3) bli synkronisert med det delte objektet før eventuelle senere revisjoner er synkronisert med det delte objektet og eventuelle konfliktskapende revisjoner er avgjort og flettet. For eksempel er revisjon R2 synkronisert med det delte objektet etter revisjon R1. Følgelig innbefatter den nyeste versjonen av det delte objektet revisjon R2. Før revisjon R3 synkroniseres med det delte objektet, blir revisjon R3 sammenliknet med revisjon R2 for å identifisere eventuelle konflikter mellom revisjonene. Sammenlikningen er nødvendig fordi revisjon R3 er en utvidelse av revisjon R1, som ikke lenger er den nyeste versjonen av det delte objektet. Revisjon R3 bestemmes å ikke være i konflikt med revisjon R2 siden utdragelement-noden 370 kan bli lagt til utdragnoden 344 uten å berøre revisjon R2.

I én utførelsesform revideres det delte objektet ved å flytte en innholdscontainer fra ett sted til et annet innenfor det delte objektet. For eksempel kan tabellnoden 340 bli flyttet fra side-noden 330 til side-noden 335. Det oppdages at tabellnoden 340 er flyttet, men det nye lagringsstedet kan ikke bestemmes. En proxy-node blir opprettet på det opprinnelige lagringsstedet til tabellnoden 340. Proxy-noden blir satt inn på det nye lagringsstedet for tabellnoden 340 når det nye lagringsstedet til tabellnoden 340 er identifisert. Dersom tabellnoden 340 slettes før det nye lagringsstedet er identifisert, blir proxy-noden kastet.

Forskjellige brukere kan redigere det delte objektet samtidig. Vanligvis reviderer brukerne forskjellige innholdscontainere i det delte objektet. Følgelig kan hver brukers revisjoner bli synkronisert med det delte objektet uten ytterligere behandling. En konflikt kan oppstå når to brukere redigerer samme innholdscontainer i det delte objektet (f.eks. samme tabellverdier, samme setning). En konflikt mellom forskjellige brukeres revisjoner kan oppstå asynkront. For eksempel kan en bruker revidere en lokalt bufret versjon av det delte objektet mens han eller hun ikke er koblet til en tjener. Revisjonene blir synkronisert med det delte objektet når brukeren igjen kobler seg til tjeneren. Revisjonene kan imidlertid være i konflikt med andre revisjoner som allerede har blitt synkronisert med det delte objektet.

For eksempel er revisjon R4 en utvidelse av revisjon R3. Revisjon R4 sletter utdragselement-noden 350 fra utdragsnoden 344. Den nyeste versjonen av det delte objektet bestemmes å innbefatte revisjon R2. En sammenlikning mellom revisjon R2 og revisjon R4 identifiserer en konflikt fordi utdragselement-noden 350 eksisterer i revisjon R2, men er slettet i revisjon R4.

En treveis fletting utføres mellom en master-versjon av en innholdscontainer og to avvikende versjoner av innholdscontaineren for å løse konfliktene. For eksempel kan innholdscontaineren RO (dvs. master-versjonen), revisjon R2 og revisjon R4 bli flettet for å frembringe den gjeldende versjonen av det delte objektet. Master-versjonen av en innholdscontainer kan være den versjonen som sist ble synkronisert med det delte objektet på tjeneren. Master-versjonen omfatter revisjoner som ikke er i konflikt.

De konfliktskapende innholdscontainerene avstemmes og flettes inn i det delte objektet ved å følge et sett av regler bestemt av en flettingsalgoritme. Flettingsalgoritmen bestemmer hvilke revisjoner som blir synkronisert med det delte objektet. For eksempel kan forskjellige brukere være rangert etter prioritet, slik at én brukers revisjoner har prioritet foran alle andre brukeres (dvs. overordnede redigeringer). Når en bruker med lavere prioritet forsøker å revidere en innholdscontainer i det delte objektet som allerede har blitt revidert av en bruker med høyere prioritet, blir brukeren informert om at revisjonene (dvs. de underordnede redigeringene) ikke vil bli synkronisert med det delte objektet. Følgelig blir de overordnede redigeringene vist på en master-side i det delte objektet, og eventuelle underordnede redigeringer blir flagget som ikke synkronisert med det delte objektet.

I et annet eksempel har revisjoner som er gjort av et delt objekt på en tjener prioritet foran revisjoner gjort lokalt på en klient. Tjenerens kopi av det delte objektet anvendes som master-versjonen fordi mange forskjellige brukere kan ha aksessert og revidert det delte objektet på tjeneren. Bare én bruker har aksessert og revidert en lokalt lagret versjon. Reviderte innholdscontainere som ikke blir synkronisert med det delte objektet (f.eks. underordnede redigeringer) blir identifisert som konfliktskapende. De konfliktskapende innholdscontainerene tas vare på ved at de blir lagret på konfliktsider for den motsvarende master-siden i det

delte objektet.

Figur 4 illustrerer en master-side i et delt objekt og en motsvarende konfliktside. Master-siden 400 omfatter ikke-konfliktskapende revisjoner, så som innholdscontainerene 410, 420. Eventuelle ikke-flettede, konfliktskapende revisjoner identifiseres på master-siden 400 av en konfliktindikator. I én utførelsesform er konfliktindikatoren en nedtrekksmeny 430. Det første elementet i nedtrekksmenyen 430 kan være de seneste konfliktene generert av brukeren. Elementet i nedtrekksmenyen 430 kan omfatte brukerens navn og et tidsstempel. Et annet element i nedtrekksmenyen 430 kan omfatte andre konfliktsider som brukeren har generert, men ikke avstemt. Andre elementer i nedtrekksmenyen 430 kan svare til konfliktsider generert av andre brukere. Valg av et element fra nedtrekksmenyen 430 viser den tilhørende konfliktsiden med de konfliktskapende revisjonene fremhevet for å rette brukerens oppmerksomhet mot revisjonene som ikke er innlemmet i master-versjonen av det delte objektet. Følgelig kan brukeren enten løse og integrere konfliktene i master-siden 400 eller bestemme at konfliktene er irrelevante.

I en annen utførelsesform er konfliktindikatoren en fane. Master-siden kan ha en tilhørende fane 440. Motsvarende konfliktsider kan også ha tilhørende faner som er annerledes enn fanen 440. For eksempel kan konfliktside-fanene være innrykket i forhold til fanen 440 eller kollapset nedenfor fanen 440. Konfliktsiden som omfatter ikke-integrerte konflikter skapt av en gitt bruker, kan være identifisert av en fane som er annerledes enn de andre fanene, slik at brukerens oppmerksomhet rettes mot konfliktsidene generert av denne brukeren. Brukeren kan da velge fanen for å navigere til den aktuelle konfliktsiden.

Det valgte konfliktsiden kan bli vist sammen med den motsvarende master-siden i det delte objektet, slik at brukeren kan avstemme og flette eventuelle konfliktskapende revisjoner med henblikk på de flettede revisjonene. Konfliktsiden 450 motsvarer master-siden 400. Konfliktsiden 450 er lik master-siden 400, bortsett fra at eventuelle konfliktskapende innholdscontainere er fremhevet for å angi at konflikten ikke er løst. For eksempel blir innholdscontaineren 460 vist med fremhevet bakgrunn for å rette brukerens oppmerksomhet mot den ubehandlede konflikten. Innholdscontaineren 460 kan ha blitt slettet og synkronisert med det delte objektet før en bruker reviderer data i innholdscontaineren 460 og dermed skaper en konflikt. Brukeren kan velge innholdscontaineren 460 for å innlemme revisjonen i

master-siden 400.

I én utførelsesform er en konfliktside forbundet med én bestemt bruker. Følgelig kan flere enn én konfliktside være svare til master-siden 400 når flere enn én bruker reviderer en side som ikke kan bli integrert. Alle konfliktskapende revisjoner blir lagret for alle brukere som har tillatelse til å aksessere det delte objektet. Brukeren som aksesserer konfliktsiden er formodentlig mest opptatt av konfliktene han eller hun har skapt, slik at vedkommende kan løse disse konfliktene. For eksempel blir Bruker 1 vist sin tilhørende konfliktside når han eller hun velger konfliktindikatoren. Brukeren kan også se en konfliktside som tilhører en annen bruker. For eksempel kan Bruker 1 velge fanen 470 for å navigere til en konfliktside tilhørende Bruker 2.

Mange konfliktsider svarende til én master-side i det delte objektet kan samle seg opp over tid. I løpet av denne tidsperioden kan brukeren ha

synkronisert flere revisjoner med master-versjonen av det delte objektet lagret på en tjener uten å ta hensyn til eventuelle motsvarende konfliktsider. Følgelig er de eldre konfliktsidene som brukeren ikke har avstemt mest sannsynlig ikke lenger relevante. I én utførelsesform kan alle konfliktsider som identifiseres

som irrelevante bli kastet etter at det har gått en forbestemt tidsperiode og brukeren har synkronisert revisjoner av siden i løpet av dette tidsrommet. For eksempel kan de tre nyeste konfliktsidene svarende til en hvilken som helst master-side bli tatt vare på, mens alle andre tilsvarende konfliktsider blir kastet én måned etter opprettelse.

I én utførelsesform blir det ikke opprettet konfliktsider under sanntidskommunikasjon fordi konflikter kan oppstå oftere enn under asynkron kommunikasjon. I stedet kan brukere samarbeide om å revidere samme innholdscontainer. Eventuelle konflikter kan løses umiddelbart siden alle brukere raskt kan avgjøre om deres revisjoner er innlemmet. Alternativt kan en bruker bli varslet om at en annen bruker reviderer en gitt innholdscontainer. Brukeren kan bli oppmuntret til å revidere en annen innholdscontainer inntil de andre brukernes revisjoner er fullført.

Figur 5 er et blokkdiagram som illustrerer et system for å synkronisere flere brukeres revisjoner av et delt objekt. Systemet omfatter klienter 500, 510, 540, 550 og tjenere 520, 530. Klienten 500 er koblet til tjenerne 520, 530. Klienten 510 er koblet til tjeneren 520. Klientene 540, 550 er koblet til tjeneren 530. Klienten 540 har et lager 542 og et underlager 544. Tjeneren 520 har et lager 522 og underlagre 524, 526. Tjeneren 530 har et lager 532. Lageret 532 innbefatter del-lagre 534, 536.

Lagrene 522, 532, underlagrene 524, 526 og del-lagrene 534, 536 kan lagre revisjoner forbundet med et delt objekt. Lagrene 522, 532, underlagrene 524, 526 og del-lagrene 534, 536 er hierarkiske. For eksempel kan lageret 522 være forbundet med et helt, felles notisbok-dokument. Underlageret 524 kan være forbundet med et kapittel av det delte notisbok-dokumentet. Underlageret 526 kan være forbundet med en side av det delte notisbok-dokumentet. I én utførelsesform er kun den nyeste versjonen av det toppnivå, delte objektet inneholdt i lageret 522. Lageret 532 kan lagre et helt toppnivå, delt objekt. Del-lagrene 534, 536 er forbundet med deler av det delte objektet. For eksempel kan del-lageret 534 være forbundet med en andel av det delte objektet, og del-lageret 536 kan være forbundet med en annen andel av det delte objektet.

Et program kan laste et delt objekt fra tjeneren 520 eller tjeneren 530 til klienten 500 som ikke har en gjeldende versjon av en gitt innholdscontainer i det

delte objektet. For eksempel ber klienten 500 om et delt objekt fra lageret 522. Den nyeste tilgjengelige versjonen av det delte objektet blir presentert ved klienten 500. Den nyeste tilgjengelige versjonen av det delte objektet svarer ikke nødvendigvis til den gjeldende versjonen av det delte objektet dersom data i den nyeste revisjonen ikke er tilgjengelige i det tilhørende underlageret 526. En forespørselsetikett tildeles underlageret 526 for å angi at klienten 500 trenger de nyeste revisjonsdataene for å oppdatere det delte objektet. Underlageret 526 kan også bli tildelt et tidsstempel som angir tidspunktet og datoen når klienten 500 ba om revisjonsdataene fra underlageret 526. Underlageret kan også bli tildelt en GUID som identifiserer klienten som ba om dataene (f.eks. klient 500). forespørselsetiketten, tidsstempelet og GUID'en anvendes for å informere klienten 500 når en annen klient aksesserer underlageret 526. For eksempel kan klienten 510 aksessere underlageret 526 med de sist oppdaterte revisjonsdataene. Følgelig informeres klienten 500 om at de sist oppdaterte revisjonsdataene for det delte objektet er tilgjengelige i underlageret 526.

Klienten 500 kan være en brukers private datamaskin og klienten 540 kan være en brukers jobbdatamaskin. Tjeneren 530 kan være en utvekslingstjenere som overfører en revisjonsfil mellom klientene 500, 540. Revisjonsfilen kan brukes til å oppdatere et delt objekt lagret på klientene 500, 550. I én utførelsesform kan ikke klienten 500 håndtere filer som er større enn en forbestemt størrelse (f.eks. 2 megabyte). For eksempel kan klienten 500 omfatte et epost-program som begrenser størrelsen til epost-meldinger som kan mottas. Lageret 542 inneholder revisjoner tilknyttet et toppnivå delt objekt. Underlageret 544 inneholder revisjoner tilknyttet en innholdscontainer i det delte objektet.

Klienten 540 kan spørre tjeneren 530 for å finne ut om en annen klient har fremsatt en forespørsel om en datarevisjon. Klienten 540 kan tilgodese forespørselen når den nyeste versjonen av den etterspurte datarevisjonen er tilgjengelig i lageret 542 eller underlageret 544. Klienten 540 kan overføre hele den etterspurte revisjonen til klienten 500 dersom revisjonsfilens størrelse er mindre enn grensen som kan behandles av klienten 500. Dersom revisjonsfilens størrelse overstiger grensen, kan filen bli delt opp i mindre filer som ikke overstiger grensen. Alternativt kan revisjonsfilens størrelse reduseres ved å slette tidligere forespørsler. De mindre filene blir da overført fra klienten 540 til klienten 500 gjennom tjeneren 530.

Flere forespørsler om revisjonsdata kan stå i kø på en tjener. I én utfør-elsesform kan forespørslene være fremsatt av forskjellige klienter (f.eks. klientene 500, 550). Hver forespørrende klient kan ha en forskjellig filstørrelsesbegrensning. For eksempel kan klienten 500 være begrenset til filer mindre enn 2 megabyte mens klienten 550 kan behandle filer opptil 20 megabyte. Derfor kan ikke begge forespørslene bli tilgodesett i én overføringstransaksjon når revisjonsfilen er større enn 2 megabyte. I én ut-førelsesform har hver forespørrende klient en tilhørende prioritetsbit som bestemmer rekkefølgen for behandling av forespørslene.

Forespørslene tilgodeses ved å synkronisere revisjonsfilen med klientene 500, 550. Revisjonsfilen kan bli synkronisert med klientene 500, 550 i én transaksjon eller gjennom en serie av flere transaksjoner avhengig av revisjonsfilens størrelse. Hver klient 500, 550 bestemmer at forespørselen er tilgodesett når hele revisjonsfilen er synkronisert. Klienten 540 kan kaste de etterspurte dataene når forespørslene er behandlet. Klienten 540 kan senere spørre tjeneren 530 for å finne ut om ytterligere forespørsler venter på å bli behandlet.

Figur 6 er et flytdiagram som illustrerer en fremgangsmåte for å synkronisere flere brukeres revisjoner av et delt objekt. Fremgangsmåten begynner i et starttrinn hvor mange brukere har tillatelse til å aksessere og revidere et delt objekt samtidig (dvs. peer-gruppen). Objektet kan være en hvilken som helst entitet som kan deles, for eksempel en fil. Peer-gruppen kan være identifisert av en gruppeidentifikator. Forskjellige versjoner av det delte objektet identifiseres av tilhørende GUID'er og tidsstempelen

Tidsstempelet angir tidspunktet når det delte objektet sist ble synkronisert med en revisjon.

I trinn 600 reviderer en bruker det delte objektet. Det delte objektet kan bli revidert på en tjener, i et lokalt hurtigbuffer eller i et peer-til-peer-nettverk. I én utførelsesform lagres revisjonen som en revisjonsfil. Videre til trinn 610 tildeles revisjonen en GUID og et tidsstempel. Tidsstempelet angir tidspunktet når brukeren reviderte det delte objektet.

Videre til trinn 620 lokaliseres den nyeste versjonen av det delte objektet. Den nyeste versjonen av det delte objektet er den versjonen som omfatter de siste revisjonene som er synkronisert med det delte objektet og gjort tilgjengelig for andre bemyndigede brukere. Den nyeste versjonen av det delte objektet kan bestemmes basert på tidsstemplene og GUID'ene til forskjellige versjoner av det delte objektet.

Videre til bestemmelsesblokk 630 bestemmes det hvorvidt det eksisterer konfliktskapende revisjoner. Konflikter mellom revisjoner kan oppstå når forskjellige brukere reviderer samme innholdscontainer. Revisjonen kan ikke bli synkronisert med det delte objektet dersom det finnes konfliktskapende revisjoner. Dersom det finnes konfliktskapende revisjoner, fortsetter fremgangsmåten i trinn 640, der de konfliktskapende revisjonene avstemmes og flettes (som beskrives i forbindelse med figur 7). Dersom det ikke finnes konfliktskapende revisjoner, fortsetter fremgangsmåten i trinn 650, der revisjonen synkroniseres med det delte objektet slik at andre brukere kan se revisjonen. Fremgangsmåten avsluttes da i et avslutningstrinn.

Figur 7 er et flytdiagram som illustrerer en fremgangsmåte for å avstemme og flette flere konfliktskapende bruker-revisjoner av et delt objekt. Fremgangsmåten begynner i et starttrinn der flere enn én bruker har revidert samme innholdscontainer i et delt objekt. En konflikt oppstår når én av de reviderte innholdscontainerene synkroniseres med det delte objektet slik at ingen andre revisjoner av innholdscontaineren kan bli synkronisert.

I trinn 700 vises den konfliktskapende revisjonen på en konfliktside. Konfliktsiden er lik den motsvarende master-siden, bortsett fra at den konfliktskapende revisjonen er fremhevet og vist i stedet for den synkroniserte revisjonen.

Videre til trinn 710 vises en konfliktindikator på master-siden i det delte objektet. Konfliktindikatoren kan være en nedtrekksmeny, en fane eller en hvilken som helst annen mekanisme som informerer en bruker om at en konfliktside er tilgjengelig for master-siden. Konfliktindikatoren for en konfliktside svarende til en gitt bruker kan være forskjellig fra konfliktindikatoren for konfliktsider svarende til andre brukere, slik at en gitt bruker raskt kan identifisere konfliktsidene generert av den aktuelle brukeren.

Videre til trinn 720 vises konfliktsiden sammen med master-siden når konfliktindikatoren velges. Brukeren får vist både den synkroniserte tilstanden til master-siden og den aktuelle konfliktsiden.

Videre til trinn 730 avstemmer og fletter brukeren konfliktskapende revisjoner til master-siden. I én utførelsesform kan brukeren velge innholdscontaineren slik at innholdscontaineren integreres med master-siden.

I en annen utførelsesform kan brukeren direkte innlemme revisjoner i master-siden. I atter en annen utførelsesform kan brukeren identifisere konfliktskapende revisjoner som irrelevante.

Videre til trinn 740 kastes konfliktskapende revisjoner som identifiseres som irrelevante. I én utførelsesform kan konfliktskapende revisjoner bli identifisert som irrelevante av en bruker. I en annen utførelsesform kan konfliktskapende revisjoner automatisk bli identifisert som irrelevante. For eksempel kan en bruker ha synkronisert flere revisjoner med master-versjonen av det delte objektet lagret på en tjener uten å ha tatt hensyn til eventuelle motsvarende konfliktsider. De eldre konfliktsidene som brukeren ikke har avstemt blir identifisert som irrelevante etter en forbestemt tidsperiode. Fremgangsmåten avsluttes da i et avslutningstrinn.

Figur 8 er et flytdiagram som illustrerer en fremgangsmåte for å synkronisere flere brukeres revisjoner av et delt objekt. Fremgangsmåten begynner i et starttrinn der forskjellige versjoner av det delte objektet lagres på forskjellige lagringssteder i et system. I trinn 800 lastes det delte objektet ned fra et lager til en klient.

Videre til bestemmelsesblokk 810 bestemmes det hvorvidt det delte objektet er den gjeldende versjonen av det delte objektet. Dersom det delte objektet er den gjeldende versjonen av det delte objektet, avsluttes fremgangsmåten i et slutttrinn. Dersom det delte objektet ikke er den gjeldende versjonen av det delte objektet, fortsetter fremgangsmåten i trinn 820. Det delte objektet er ikke nødvendigvis den gjeldende versjonen dersom den siste revisjonen av en innholdscontainer i det delte objektet ikke er tilgjengelig fra lageret.

Videre til trinn 820 tildeles en forespørselsetikett og klientinformasjon til lageret for å angi at klienten trenger de nyeste revisjonsdataene for å oppdatere det delte objektet. Klientinformasjonen kan omfatte en GUID som identifiserer klienten som fremsatte forespørselen, og et tidsstempel som angir tidspunktet når klienten ba om den gjeldende versjonen av det delte objektet fra lageret.

Videre til trinn 830 mottas den gjeldende versjonen av det delte objektet ved lageret. Lageret kan motta den gjeldende versjonen av det delte objektet når en annen klient aksesserer lageret med de nyeste revisjonsdataene. Klienten som fremsatte forespørselen informeres om at den gjeldende versjonen av det delte objektet er mottatt ved lageret. Videre til trinn 840 synkroniseres den gjeldende versjonen av det delte objektet med klienten som fremsatte forespørselen. Fremgangsmåten avsluttes da i et

avslutningstrinn.

Figur 9 er et flytdiagram som illustrerer en fremgangsmåte for sømløs overgang fra asynkron til synkron kommunikasjonsmodus. Fremgangsmåten begynner i et starttrinn der en peer-gruppe opprettes som identifiserer brukere som er bemyndiget til å aksessere et delt objekt.

I trinn 900 aksesserer en klient det delte objektet på en tjener. Klienten kobles automatisk til andre klienter som også aksesserer det delte objektet (dvs. peer-gruppen). Det delte objektet har en tilhørende spesifikasjonsfil. Det delte objektet innbefatter en unik stedsidentifikator som angir lagringsstedet hvor den tilhørende spesifikasjonsfilen er lagret i systemet.

Videre til trinn 910 hentes spesifikasjonsfilen frem fra lagringsstedet identifisert av den unike stedsidentifikatoren. Spesifikasjonsfilen identifiserer lagringsstedene hvor andre versjoner og instanser av det delte objektet er lagret innenfor systemet. Spesifikasjonsfilen omfatter en gruppeidentifikator for peer-gruppen hvor en versjon av det delte objektet er lagret.

Videre til trinn 920 opprettes et peer-til-peer-nettverk når en hvilken som helst annen klient i peer-gruppen aksesserer en versjon eller instans av det delte objektet identifisert av spesifikasjonsfilen. Følgelig kan klienten koble seg fra tjeneren og fortsatt aksessere den delte filen i peer-til-peer-nettverket. Fremgangsmåten avsluttes da i et avslutningstrinn.

Figur 10 er et flytdiagram som illustrerer en fremgangsmåte for sømløst å skifte fra synkron til asynkron kommunikasjonsmodus. Fremgangsmåten begynner i et starttrinn der et peer-til-peer-nettverk opprettes mellom minst to brukere som er bemyndiget til å aksessere et delt objekt.

I trinn 1000 aksesserer en klient det delte objektet i peer-til-peer-nettverket. Det delte objektet har en tilhørende spesifikasjonsfil. Det delte objektet innbefatter en unik stedsidentifikator som identifiserer lagringsstedet hvor den tilhørende spesifikasjonsfilen er lagret i systemet.

Videre til trinn 1010 hentes spesifikasjonsfilen tilhørende det delte objektet frem fra lagringsstedet identifisert av den unike stedsidentifikatoren. Spesifikasjonsfilen identifiserer lagringsstedene hvor andre versjoner og instanser av det delte objektet er lagret innenfor systemet. Videre til trinn 1020 kobler klienten seg til en tjener. Klienten bestemmer hvilke andre klienter som også er koblet til tjeneren. Videre til trinn 1030 identifiserer klienten andre klienter som er bemyndiget til å aksessere det delte objektet over peer-til-peer-nettverket. Videre til trinn 1040 kobler klienten seg til en autorisert klient når peer-til-peer-nettverket er utilgjengelig. Fremgangsmåten avsluttes da i et avslutningstrinn.

Beskrivelsen, eksemplene og informasjonen over gir en fullstendig beskrivelse av realisering og bruk av oppfinnelsen. Siden mange utførelses-former av oppfinnelsen kan gjøres uten at man fjerner seg fra oppfinnelsens ramme og idé, defineres oppfinnelsen av de etterfølgende kravene.

Claims (14)

1. Datamaskin implementert fremgangsmåte for å synkronisere flere brukerrevisjoner av et delt objekt (252, 264, 272), omfattende det å: motta en revisjon av det delte objektet, aksessere (900,1000) det delte objektet på en server (250) for å danne en asynkron server kommunikasjons modus mellom en klient (220) og serveren (250); bestemme stedet til en spesifikasjons fil (254, 266) assosiert med det delte objektet basert på et unikt sted identifisert i det aksesserte objektet; hente (910, 1010) spesifikasjonsfilen på klienten basert på den unike stedsidentifikator i det aksesserte delte objektet, hvor spesifikasjonsfilen identifiserer stedet hvor andre forskjellige versjoner av det delte objektet er lagret; basert på den hentede spesifikasjonsfilen å gå over, på en automatisk og sømløs måte, fra den asynkrone server kommunikasjonen til en likemanns kommunikasjons modus ved å etablere et likemanns-til-likemanns nettverk med andre klienter som aksesserer en versjon av det delte objektet identifisert av spesifikasjonsfilen; motta en revisjon av det delte objektet på klienten der revisjonen er assosiert med en global unik identifikator, GUID; og et tidsstempel, der tidsstempelet identifiserer tidspunktet revisjonen var laget på; bestemme, basert på tidsstempelet og GUID, om revisjonen er tilgjengelig fra likemanns-til-likemanns nettverket; og dersom revisjonen ikke er tilgjengelig fra likemanns-til-likemannsnettverket, å sende revisjonen til likemanns-til-likemanns nettverket.

2. Fremgangsmåte ifølge krav 1, videre omfattende det å: avgjøre om revisjonen er irrelevant, og kaste revisjonen som bestemmes å være irrelevant.

3. Fremgangsmåte ifølge krav 1, videre omfattende det å: motta en forespørsel fra en klient om en gjeldende versjon av det delte objektet ved et lager, motta den gjeldende versjonen av det delte objektet ved lageret.

4. Fremgangsmåte ifølge krav 3, der det å motta en forespørsel fra en klient videre omfatter det å tildele en forespørselsetikett og klientinformasjon til lageret.

5. Fremgangsmåte ifølge krav 3, der det å motta den gjeldende versjonen av det delte objektet videre omfatter det å motta den gjeldende versjonen av det delte objektet når en annen klient aksesserer lageret med den gjeldende versjonen av det delte objektet.

6. Datamaskin-lesbart medium med datamaskin-eksekverbare instruksjoner for å synkronisere flere brukerrevisjoner av et delt objekt, omfattende det å: aksessere (900, 1000) det delte objektet på en server (250) for å danne en asynkron server kommunikasjons modus mellom en klient (220) og serveren (250); bestemme stedet til en spesifikasjons fil (254, 266) assosiert med det delte objektet basert på et unikt sted identifisert i det aksesserte objektet; hente (910, 1010) spesifikasjonsfilen på klienten basert på den unike stedsidentifikator i det aksesserte delte objektet, hvor spesifikasjonsfilen identifiserer stedet hvor andre forskjellige versjoner av det delte objektet er lagret; basert på den hentede spesifikasjonsfilen å gå over, på en automatisk og sømløs måte, fra den asynkrone server kommunikasjonen til en likemanns kommunikasjons modus ved å etablere et likemanns-til-likemanns nettverk med andre klienter som aksesserer en versjon av det delte objektet identifisert av spesifikasjonsfilen; motta en revisjon av det delte objektet på klienten der revisjonen er assosiert med en global unik identifikator, GUID; og et tidsstempel, der tidsstempelet identifiserer tidspunktet revisjonen var laget på; bestemme, basert på tidsstempelet og GUID, om revisjonen er tilgjengelig fra likemanns-til-likemanns nettverket: og dersom revisjonen ikke er tilgjengelig fra likemanns-til-likemanns nettverket, å sende revisjonen til likemanns-til-likemanns nettverket.

7. Datamaskin-lesbart medium ifølge krav 6, videre omfattende det å: avgjøre om revisjonen er irrelevant, og kaste revisjonen som bestemmes å være irrelevant.

8. Datamaskin-lesbart medium ifølge krav 6, videre omfattende det å avgjøre om revisjonen er relatert til en gjeldende versjon av det delte objektet.

9. Datamaskin-lesbart medium ifølge krav 8, videre omfattende det å: motta en forespørsel fra en klient om en gjeldende versjon av det delte objektet ved et lager, motta den gjeldende versjonen av det delte objektet ved lageret.

10. System for å synkronisere flere brukerrevisjoner av et delt objekt, omfattende: mekanisme for å aksessere (900, 1000) det delte objektet på en server (250) for å danne en asynkron server kommunikasjonsmodus mellon en klient

(220) og serveren (250); mekanisme for å bestemme stedet til en spesifikasjonsfil (254, 266) assosiert med det delte objektet basert på et unikt sted identifisert i det aksesserte objektet; mekanisme for å hente (910, 1010) spesifikasjonsfilen på klienten basert på den unike stedsidentifikator i det aksesserte delte objektet, hvor spesifikasjonsfilen identifiserer stedet hvor andre forskjellige versjoner av det delte objektet er lagret; mekanisme for å gå over, på en automatisk og sømløs måte, fra den asynkrone server kommunikasjonen til en likemanns kommunikasjonsmodus ved å etablere et likemanns-til-likemanns nettverk med andre klienter som aksesserer en versjon av det delte objektet identifisert av spesifikasjonsfilen; mekanisme for å motta en revisjon av det delte objektet på klienten der revisjonen er assosiert med en global unik identifikator, GUID; og et tidsstempel, der tidsstempelet identifiserer tidspunktet revisjonen var alget på; mekanisme for å bestemme, basert på tidsstempelet og GUID, om revisjonen er tilgjengelig fra likemanns-til-likemanns nettverket: og mekanisme for å sende revisjonen til likemanns-til-likemanns nettverket dersom revisjonen ikke er tilgjengelig fra likemanns-til-likemannsnettverket.

11. System ifølge krav 10, videre omfattende: en mekanisme for å motta en forespørsel fra en klient om den gjeldende versjon av det delte objektet ved et lager, en mekanisme for å motta den gjeldende versjonen av det delte objektet ved lageret.

12. System ifølge krav 11, der mekanismen for å motta en forespørsel fra en klient videre innbefatter en mekanisme for å tildele en forespørselsetikett og klientinformasjon til lageret.

13. System ifølge krav 11, der mekanismen for å motta den gjeldende versjonen av det delte objektet videre omfatter en mekanisme for å motta den gjeldende versjonen av det delte objektet når en annen klient aksesserer lageret med den gjeldende versjonen av det delte objektet.

14. System ifølge krav 10, videre omfattende en mekanisme for å avgjøre om revisjonen er relatert til den gjeldende versjonen av det delte objektet.