20
Iwillnotconsiderthesesocialproblemshere,butratherconcentrateonconsequences
andimplicationsforsystemsdesign.GreenbergandMarwood(GreenbergandMarwood1994)
haveexaminedtheinterfaceanomaliesthatarisewithanyformofgroupconcurrencycon-
trolforsynchronouseditors.Mostoftheseanomaliesinvolveeitherunexpectedscreenup-
dates,orinabilitytoeffectachange,despiteaninterfacestatethatseemstoallowit.This
problemisunavoidabletosomeextentsincethereisnowayforchangestobeinstantane-
ouslyshared.Sincetheirpaperexaminesonlyreal-timecollaborationtools,basedonthe
conceptofasinglesharedstate,itdoesnotconsiderthepotentialadvantagesofallowing
differentviewsatdifferentinstancesofaneditor.
Enablingcoordination,inthiscase,amountstogivingusersawaytoselectivelyundo
eachother’schangesandupdates.Thisessentiallymovestheresponsibilityforarbitrationof
userchangesfromtheapplicationbacktothecollaborators.Thismayactuallyimprovethe
possibilitiesforcollaboration,byallowingawidervarietyofpotentialworkingstyles,de-
pendingontheauthors’needs,andthestateofaproject.Infact,out-of-sequenceundo
turnsouttobenecessaryformulti-userediting,evenatalowlevel,sinceindividualusers
maywanttoundotheirownchangesevenaftertheirlocalapplicationhasreceivedfurther
updatesfromotherusers.Thegeneralproblemofmulti-userundoisreallytobeableto
undooperationsregardlessoftheirtemporalorderofoccurrence.
Avarietyofsingle-userundoschemeshavebeenimplementedovertheyears.(Vitter
1984)providesagoodsurveyofundomodels,whichhavereallynotchangedthatmuchin
theinterim.Whileundohasgenerallybeenanimplementer’sproblem,someundomodels
(Archer,Conwayetal.1984;Leeman1986)havebeenformalized.Mostoftheexplorationof
variationinundotechniqueshasbeenfocusedontheproperchoiceofundofacilitiestopro-
videasingleuserofatexteditor.Thequestionmostatissueiswhatlogicalmodelsaremost
directlyusefulascommandsforasingleusertoexecuteduringasingleeditingsession.
21
Theproblemwithundoingroupworkisthatmanyofthesimplifyingassumptionspossi-
bleinasingle-usereditoraresimplyunreasonableinamulti-usersituation.Forinstance,
onethingthatrequiresmodificationisthenotionthatauser’schangescanbeundonein
thereverseorderthattheywereperformed,eventhoughonegoodwaytoresolveaconflict
amongusersistosimplyundosomeoftheproblematicchanges.Thelinearundomodelfails
becauseauser’sownchangesmayhavebeenfollowedbychangesmadebyotherusers,so
thatundoingone’sownchangesisimpossiblewithoutalsoundoingthosemadebyanother
user,eveniftheyoccurinanotherpartoftheobjectbeingedited.Thesamesituationcan
occuranytimeauserattemptstoundoanychange,infact,sincetheorderofusernotifica-
tionofchangesnotinfrequentlyvariesfromeditinginstancetoeditinginstance.
Asinanumberofotherareasofcollaborativeediting,synchronousandasynchronous
editinghavebeenhandleddifferently,andmostsystemshaveconcentratedononeorthe
other.Thesynchronouscasehasreceivedthemostattention,asundoisoneoftheproblems
thatcropsupimmediatelyoncesimultaneouseditingisenabled.Oneapproachistorewinda
historicallogofchangesandthenreplaythem,withoutthechangetobeundone,andthen
broadcastachangecancellationtotheotherinstancesoftheeditor.Thisapproachistaken
in(PrakashandKnister1992;ChoudharyandDewan1995).Thesesystemsextendopera-
tionaltransformationtosupportthis,byusingittotransformoperationsbeforeredoing
them.Localeditorsmustretainenoughhistorytobacktrackandundospecificoperations.
Thistechniquedoesnotworksowellifoff-lineaswellason-linecollaborationissupported
bythesystem,sincethenumberofchangesinvolvedcanbequitelarge,evenforarelatively
shorteditingperiod.
Infact,algorithmicsolutionshavebeenrathersparinglyappliedtothisprobleminthe
asynchronouscase,exactlybecausethetypicaldivergencebetweenseparatelong-term
transactionsislarge.Thefocushasgenerallybeenonpreventingconflictsbymeansof
lockingorversioning(asinthesoftware-engineeringdomain)oronthedetectionof
Previous Page Next Page