Research and Development 1/^Archief/2009-2010/05/Pilot/Verslag

"Pilot Verslag" komt niet voor in de lijst (Logboek, Planning, Projectpagina, Pilot, Fase 1, Fase 2, Groepspagina, Feedback) met mogelijke waarden voor de eigenschap "Type".

Abstract

Een abstract is een verkorte versie van het hele verslag, en moet, kort, de volgende dingen aan de lezer duidelijk maken:

• Onderzoeksdoelen
• Onderzoeksmiddelen
• Onderzoeksresultaten
• Conclusies

Deze schrijven we pas als laatst.

Inleiding

Aanleiding

Google Wave is een krachtig gereedschap voor samenwerking. Sommigen zien dit zelfs als 'het nieuwe emailen'. Emailen waarbij men elkaars mails kan lezen, aanpassen, beantwoorden of verwijderen. Deze veranderingen worden ook nog eens real-time bijgewerkt, dus samenwerken gaat gemakkelijk zonder achteraf conflicts te moeten bijwerken. Een geweldig setje gereedschap voor samenwerking met de potentie om emailen te vervangen. Ware het niet dat er iets fundamenteels ontbreekt. Er zijn op dit moment nog te weinig vrije implementaties van dit systeem.

Iedereen kan een eigen email server opzetten. Zo draait een bedrijf ook meestal zijn eigen email server. Alle emails gaan dus via het bedrijf zelf en komen wat emails van medewerker naar medewerker betreft, nooit naar buiten. Dit kan bijvoorbeeld bij samenwerking over bedrijfsgevoelige informatie gewenst zijn, maar ook bij andere privacy-gevoelige zaken.

Verder waren er ook nog bezwaren te bedenken tegen de specifieke web-based client van Google. Web based implementaties zijn overal te bereiken, uitgaand van een werkende internetverbinding (en waarom zou je uberhaupt in een real-time wave willen werken zonder internet, het hele wave-idee werkt dan toch niet), en een ondersteunde webbrowser. Maar niet iedereen wil dit. Er zijn verschillende argumenten tegen te bedenken, zoals het ontbreken de mogelijkheid om offline te kunnen werken (zo zou iemand al lokaal een document kunnen maken, en deze zodra hij een internetverbinding krijgt kunnen versturen). Ook is er in een echt losstaande client meer mogelijk en vooral meer snelheid mogelijk.

Ons doel voor deze cursus is dan ook om een clientside applicatie voor Wave te ontwikkelen, waarbij de server-kant van deze applicatie ontwikkeld wordt

door Groep 14. Om zo'n applicatie te realiseren, is een duidelijk communicatieprotocol tussen client en server nodig. Dit ontbreekt nog, dus daar ligt de focus van dit verslag; het specificeren van een client-server protocol voor Wave.

Protocoleigenschappen

Wat we gaan beschrijven is een internetcommunicatie-protocol. De volgende feiten moet zo'n protocol minstens beschrijven:

• hoe er een (veilige) verbinding tussen partijen tot stand komt
• hoe verstuurde en ontvangen berichten er uit dienen te zien
• wanneer welke berichten verstuurd mogen worden
• wat te doen met corrupte en niet goed opgestelde berichten
• hoe de communicatiesessie af te sluiten

Onder alle documenten en code die door Google aan de wereld beschikbaar is gesteld, is ook een beschrijving aanwezig van een client-server protocol. Een beschrijving in natuurlijke taal is op zichzelf niet genoeg om een implementatie te realiseren. We hebben ervoor gekozen om vanuit deze beschrijving verder te bouwen, tot we een specificatie verkrijgen die aan de hierboven gestelde feiten en punten voldoet. Daartoe is het eerst nodig om een formelere, eenduidigere beschrijving op te stellen, voordat we de informatie kunnen gebruiken. Het is deel van onze doelstellingen om een zo groot mogelijke compatibiliteit met andere Wave systemen te behouden, vandaar de keuze om zo dicht mogelijk bij beschrijvingen van Google te blijven.

Huidig client-server protocol

De huidige client-server protocol specificatie(bron? is niet compleet. Dit leiden wij af uit het feit dat dit protocol niet verteld over hoe een verbinding tot wordt gebracht, overgezonden berichten opgemaakt dienen te zijn, hoe authenticatie plaats vindt, en tot welke informatie de client op welke momenten toegang tot heeft. Daarnaast worden begrippen zoals 'Wave' en 'Wavelet' door elkaar gebruikt, worden begrippen geïntroduceerd en niet compleet toegelicht, en worden bepaalde begrippen geïntroduceerd en helemaal niet toegelicht. Wij hebben aan de hand van andere bronnen van Google over Wave en Google's implementatie van Wave af te leiden wat dan wel de juiste begrippen zijn. Het resultaat staat hierboven, in de vorm van de begrippenlijst. Daar waar we niet binnen één uur een definitie konden vinden, hebben we deze zelf bepaald conform met onze doelen.

Federation protocol

Het Federation-protocol bevat ook al een aantal van de eerder genoemde feiten en punten. Het is aannemelijk om de basis van dit protocol over te nemen en hier op verder te bouwen. Juist dit, omdat als we dicht bij het federation protocol blijven, client en vooral server niet extra modules nodig hebben om berichten om te zetten naar een andere vorm. Je vermijd zo complexiteit. Bovendien lijkt het ons logisch om aan te nemen dat ontwerpers van het Federation protocol goed hebben nagedacht over hun specificatie. Het lijkt ons ook waarschijnlijk dat de meerderheid van de ontwikkelaars die een eigen Wave implementatie willen creëren, deze twee argumenten ook inziet. Hieruit leiden wij af dat we zo ook dichter bij andere toekomstige implementaties van Wave blijven, en zo koppeling van onze client met vreemde servers makkelijker maken.

Het Federation protocol, of volledig gezegd: "The Google Wave Federation Protocol Over XMPP" is een open extensie op de XMPP Core protocol, die bijna realtime communicatie tussen servers mogelijk maakt. De XMPP specificaties laten een aantal keuzes vrij voor specifieke wensen, waar Google nog een aantal keuzes beperkt bij zijn Wave protocol wat betreft authenticatie en berichtvorm.

Over Authenticatie schrijft Google het volgende:

• "As an XMPP extension, this protocol expects a bidirectional stream to be established according to the XMPP core specification.
• The connection MUST be secured using the TLS feature of XMPP. It is RECOMMENDED that communication is encrypted (namely by using a non-identity TLS cipher)."

En over berichtvorm het volgende:

• "All communication except wavelet updates are sent via PubSub (, “XMPP Publish Suscribe,” September 2008.) [XEP0060] events."
• "Wavelet updates are sent using Message stanzas."

XMPP

Het Extensible Messaging and Presence Protocol (XMPP) is een communicatieprotocol om met behulp van Extensible Markup Language (XML) gestructureerde informatie uit te wisselen. Het is goed geschikt voor bijna real-time berichtuitwisseling, en vraag-antwoord services. Dit protocol is een logische keuze voor ons, omdat het open, makkelijk uitbreidbaar en flexibel is. Ook wordt het veel gebruikt, en zijn er al een hoop bruikbare implementaties van XMPP clientsystemen te vinden waar wij op voort kunnen bouwen. XMPP vereist geen vaste netwerkarchitectuur, maar het is wel makkelijk om altijd van een client-server architectuur te spreken. Hier moet wel het onderscheid tussen XMPP client/server en Google Wave client/server rollen duidelijk blijven. Het grote verschil is dat een Google Wave server ook als client kan dienen ten opzichte van een andere Google Wave server, als de client in dit geval nieuwe gegevens ontvangt en moet doorsturen.

In het Google Wave protocol is onderscheid te maken tussen twee soorten van communicatie:

• Vraag-Antwoord: de client en server communiceren op basis van vraag en antwoord. De client stelt een vraag, en de server geeft een antwoord. Als de client om een wijziging vraagt geeft de server een acknowledgement (vaak afgekort als Ack), ofwel een bevestiging dat het is gewijzigd. Een voorbeeld van deze vorm van communicatie is het doorgeven van een wijziging op een wavelet van de client aan de server.
• Pushing: de server pusht gegevens naar de client. Dit houdt in dat de client nergens om vraagt maar alleen luistert. De server notificeert de client van veranderingen waar de client zich aan moet houden. Een voorbeeld van deze vorm van communicatie is als de server aan al zijn geinterresseerde clients doorgeeft dat een bepaalde wavelet is gewijzigd.

PubSub

Voor de vraag-antwoord communicatie is de XMPP Core voldoende. Echter bied dit geen push functionaliteit. Het zou heel lastig zijn om wijzigingen die via een bepaalde client de server binnenkomt heel gauw bij alle andere geinterresseerde clients te krijgen via vraag-antwoord. Hiervoor hebben we iets anders nodig, een pushnotificatie systeem. De client blijft luisteren en de server stuurt de meldingen. Dit is waarvoor PubSub is ontworpen. PubSub is een uitbreiding op de XMPP Core waarmee Publish-Subscribe mogelijkheden worden verwezelijkt. Dit systeem werkt zo dat er gegevens bij een Node wordt gepubliceert bij de server, en de server pusht deze gegevens door naar alle geinterresseerden. Een node is hier op te vatten als een onderwerp, en de geinterresseerden zijn alle clients die zich bij de server hebben gesubscribed (ingeschreven) voor deze node. Nu is bijvoorbeeld het openen van een wave op te vatten als het subscriben bij de bijbehorende node.

"Hier komt een stuk over hetgeen dat nog ongedefinieerd is, en in de rest van het verslag verder uitgewerkt dient te worden."

Onderzoeksvragen

We hebben voor onszelf een grens en een aantal mijlpalen gezet, van wat we nu willen doen met dit protocol binnen de beschikbaar gestelde tijd. Het resultaat hiervan is een deelverzameling van de functionaliteiten die de huidige implementatie van Google's Wave biedt. Om welke functionaliteiten het precies gaat, is opgenomen in onze Mijlpalen van implementatie. In het kader van deze functionaliteiten, hebben we besloten dat ons protocol minstens de volgende dingen moet vaststellen, vanuit de client gezien:

• Het maken van een veilige en geautoriseerde verbinding tussen client en server.
• Het verkrijgen van informatie over de Wave status.
• Het verkijgen van gehele Waves.
• Het ontvangen van notificaties over Delta's.
• Het verkijgen van Delta's.
• Het verzenden van Delta's.
• Het aanmaken van nieuwe documenten.

De volgorde waarin deze punten staat, heeft betrekking tot de volgorde waarin ze in een doelsituatie gebruikt worden. Eerst autorisatie, dan synchronisatie, bewerkingen en nieuwe berichten / Waves aanmaken.

Wat ons nu rest, is uitzoeken hoe deze punten wel of niet uit de bekende theorie volgt, en hoe we hetgeen dat niet gedefinieerd staat moeten opschrijven.

We kunnen dit proces opsplitsen in een aantal onderzoeksvragen:

1. Welk van de hierboven geformuleerde functionaliteiten is direct te formuleren uit al bekende theorie?
2. Welk van de hierboven geformuleerde functionaliteiten die niet direct te definiëren zijn, zijn dat wel na formalisering?
3. Welk van de hierboven geformuleerde functionaliteiten wordt überhaupt nog niks over verteld?

Als resultaat willen de antwoorden op deze vragen presenteren, tesamen met de bijbehorende specificatie waarop de vragen slaan.

Hypothesen

We hebben ook vermoedens over de antwoorden op deze vragen. Met betrekking tot de eerste vraag denken wij dat:

• "het maken van een veilige en geautoriseerde verbinding tussen client en server" al gespecificeerd staat in het XMPP Core protocol. Juist omdat dit protocol gaat over het maken van verbindingen en het oversturen van berichten.
• "het ontvangen van notificaties over delta's" af te leiden is uit de PubSub specificatie. Juist omdat dit protocol de Observer-pattern structuur implementeert, waarbij het draait om het versturen van notificaties.

Met betrekking tot de tweede vraag denken wij dat:

• "het verkrijgen van informatie over de Wave status", en
• "het verkrijgen van gehele Waves", en
• "het verkrijgen van delta's", en
• "het verzenden van delta's", nog gespecificeerd moeten worden, maar dat de XMPP Core specificatie ons op weg helpt. Juist omdat dit protocol wel iets zegt over het oversturen en verkrijgen van berichten.

Met betrekking tot de derde vraag denken wij dat:

• "het aanmaken van nieuwe documenten" nog volledig gespecificeerd moet worden, omdat we tot dusver niks hebben kunnen vinden over het creëren van nieuwe bestanden, slechts het wijzigen van bestaande bestanden.

Methoden

Ons onderzoek is voornamelijk een literatuuronderzoek. Om antwoorden te vinden op deze vragen, en om aan de hand van die antwoorden specificaties op te schrijven, moeten we voornamelijk de open gestelde literatuur door Google raadplegen. Plan van aanpak is:

1e Onderzoeksvraag

• Protocollen doorlezen

• Staat een van de functionaliteiten of eigenschappen in detail genoteerd, ja/nee?

Zo ja, noteer specificatie(basis) en zoek de volgende functionaliteit.

Zo nee, ga verder met deze functionaliteit voor de tweede onderzoeksvraag.

2e Onderzoeksvraag

• Protocollen doorlezen

• Staat er een ruwe omschrijving van de functionaliteit of eigenschap genoteerd, ja/nee?

Zo ja, noteer de omschrijving.

Zo nee, ga verder met deze functionaliteit voor de derde onderzoeksvraag.

De genoteerde omschrijvingen moeten vervolgens gecheckt worden op ambiguïteit, ontbrekende

uitleg en ontbrekende uitleg van begrippen. De omschrijving moet dan omgeschreven worden

naar een vorm die eenduidig en specifiek is, in natuurlijke taal.

3e Onderzoeksvraag

• Zelf een duidelijke en beargumenteerde keuze maken voor een definitie.

Resultaten

Uit ons onderzoek zijn een aantal conclusies te trekken. Hier volgt ons antwoord op de door ons gestelde onderzoeksvragen, met betrekking tot de door ons vereisde functionaliteit.

Functionaliteiten

• Het maken van een veilige en geautoriseerde verbinding tussen client en server.
• Het verkrijgen van informatie over de Wave status.
• Het verkijgen van gehele Waves.
• Het ontvangen van notificaties over Delta's.
• Het verkijgen van Delta's.
• Het verzenden van Delta's.
• Het aanmaken van nieuwe documenten.

Vragen

Welk van de hierboven geformuleerde functionaliteiten is direct te formuleren uit al bekende theorie?

• Het maken van een veilige en geautoriseerde verbinding tussen client en server.

Het Google Wave Federation Draft Protocol Specification document is duidelijk dat we een verbinding aan moeten maken volgens de in de XMPP Core Specifications opgestelde regels, en dat deze via TLS moet worden beveiligd.

Welk van de hierboven geformuleerde functionaliteiten die niet direct te definiëren zijn, zijn dat wel na formalisering?

• Het verkijgen van gehele Waves.

Hier spreekt het Client Server Protocol al wat duidelijkere taal, maar dit moest alsnog worden gekoppeld aan XMPP. Dit komt neer op een volgens de XMPP PubSub gespecificeerde Subscribe. De opbouw van de gegevens in de wave zelf zijn wat duidelijker gespecificeerd in het Google Wave Conversation Model.

• Het ontvangen van notificaties over Delta's.
• Het verkijgen van Delta's.
• Het verzenden van Delta's.

In het Client Server Protocol stond wel het een en het ander over hoe we om moesten gaan met versturen en ontvangen van Delta's, maar dit zou onmogelijk via een XMPP request kunnen. We kunnen dit beter bekijken op de volgende manier: Bron b stuurt delta d aan de server. Deze bron (de client zelf, of een andere bron) heeft dan een item (delta d) gepublished aan de Node (Wave) via de door XMPP PubSub gespecificeerde Publisher Publish, hierna volgt in de specificatie hoe deze verder moet worden gepushed naar de geinterresseerde clients.

Welk van de hierboven geformuleerde functionaliteiten wordt überhaupt nog niks over verteld?

• Het verkrijgen van informatie over de Wave status.

De specificaties van Google zelf lieten hiernaar gissen. Uit de XMPP PubSub specificaties volgt dat we informatie over de Wave (die in dit geval een Node is) op kunnen halen met behulp van Node Discovery.

• Het aanmaken van nieuwe documenten.

Hier wordt helemaal niet over gesproken in de gehele Google Wave Documentatie.

Conclusie & Discussie

Alle hierboven gevonden resultaten zullen wij hier formuleren als een duidelijk en implementeerbaar protocol.

Dit onderdeel van het verslag zal verder beschrijven wat uit ons onderzoek is gekomen en hoe wij het google wave client -serverprotocol opvatten.

Wave model

Om over communicatie van een Wave Service te praten, is het nodig een model op te stellen zodat we na kunnen denken over dit protocol. Hiertoe definiëren wij, m.b.v. de originele definities van Google, hieronder een begrippenlijst en een aantal eigenschappen van deze begrippen.

Begrippenlijst

• Wave := Een verzameling van minstens één Wavelet.

• Wavelet := Een verzameling van documenten en één participantList. Een Wavelet is het domein van operations.
• childWavelet := Er bestaat een Wavelet n en een Wavelet m, waarvoor geldt: m is een kind van n.
• parentWavelet := Er bestaat een Wavelet n en een Wavelet m, waarvoor geldt: n is een kind van m.

Hierbij zegt de relatie ' m kind n' dat Wavelet n, Wavelet m bevat.

• Document := Een document bestaat uit XML elementen, die zijn opgemaakt met ranged key-value stijlelementen.
• Conversation Manifest := Een document met daarin de structuur van een gesprek; de structuur van blips.
• Blip := Een document met daarin gespreksinformatie.
  

• participantList := Een lijst met daarin unieke participanten, die allen de Wavelet van de participantList mogen bekijken en eventueel bewerken.
• participant := Eén gebruiker OF één groep van gebruikers, die gebruik maakt van de Wave service die een Server de participant via een client aanbiedt.

• Wave view := De verzameling van Wavelets in één Wave, waar één gebruiker toegang tot heeft.

• operations := Bewerkingen die een participant op een Wavelet kan uitvoeren.
• Delta := Een lijstje met één of meer operaties.

• History Hash := Een hash van een Wavelet, die in combinatie met een versienummer gebruikt wordt om synchronisatie mogelijk te maken.

• Client := Representeert een participant in de participantList, die een service bij de server aanvraagt.
• Server := De server biedt de Wave service aan zijn clients aan.
• Master Server := Een server is Master Server van een Wave, als een client deze Wave bij deze Server heeft aangemaakt.

Identificatie

Wave Identificatie

Een Wave wordt geïdentificeerd door een globaal unieke Wave ID. De Wave ID bestaat uit een samenstelling van het domein van de Wave Server van de maker van de Wave, en een unieke ID string. Een voorbeeld van een Wave ID is: "googlewave.com!w%252BvGFICaQ7I", waarbij "googlewave.com" het domein is, en "w%252BvGFICaQ7I" de unieke ID string.

Wavelet Identificatie

Een Wavelet wordt geïdentificeerd door een Wavelet ID, die uniek is binnen de Wave waar de Wavelet een deelverzameling van is. De Wavelet ID bestaat uit en samenstelling van het domein van de Wave Server van de maker van de Wavelet, en een unieke ID string. Een voorbeeld van een Wavelet ID is: "initech-corp.com!conv+3sG7", waarbij "initech-cop.com" het domein is, en "conv+3sG7" de unieke ID string.

Document Identificatie

Doumenten worden geïdentificeerd door een Document ID, die uniek is binnen de Wavelet die het document bevat. De Document ID bestaat uit een samenstelling van een Document namespace en een ID String. De Document namespaces zijn: 'b' voor blips en 'conv' voor Conversation Manifest documenten. Een voorbeeld van een Document ID is: "b+a", waarbij "b" de document namespace is, en "a" de unieke ID string.

Participant Identificatie

Een participant wordt geïdentificeerd door een participant ID die uniek is binnen het domein van de server waarmee de client van de participant communiceert. De participant ID bestaat uit een samenstelling van een gebruikersnaam en het domein van de Wave Server waarmee de client van de participant communiceert. Een voorbeeld van een participant ID is "foo@wavesandbox.com", waarbij "wavesandbox.com" het domein is, en "foo" de gebruikersnaam.

Naast deze definities hebben we de volgende eigenschappen van het protocol uit de pagina geabstraheerd:

Client verantwoordelijkheden

• Clients mogen alleen de Wave Views van de participant die de client bedient bezitten.
• Servers mogen alleen de verzameling van Wave Views bezitten die hun clients mogen bezitten.
• Clients zijn verantwoordelijk voor het correct toepassen van delta's die ze van hun server ontvangen.
• De toestand van een Wavelet is geheel gedefinieerd door een lijst van toegepaste operations tot dat moment.
• Alle uitgevoerde operations door deelnemers van de Participantlist, worden doorgestuurd naar en verwerkt door de Master Server.

Operation ordening

Om op alle clients dezelfde Wave State te behouden, dienen gedane operaties overgestuurd te worden, en gesorteerd op moment van toepassingen. Om dit te verwezenlijken door alle veranderingen te timestampen, is een fout gevoelig proces. Het is namelijk erg moeilijk om op veel systemen exact dezelfde tijd te hanteren. Daarnaast moet nog een heel proces bedacht en geïmplementeerd worden, zodat alle states de zelfde hebben, houden of weer krijgen. Vandaar dat in het Federation protocol voor een andere oplossing gekozen is. De gebruikte techniek heet Operational Transformation (OT). Deze implementeert een functie Transform(), die een toe te passen operatie transformeert naar iets dat klopt binnen de context. Zo kan in theorie synchronisatie verwezenlijkt worden. De Wave implementatie van OT vereist dat te verwerken delta's geordend moeten zijn op een bijgegeven versienummer. Daarbij is een versienummer een integer die begint bij 0 en steeds met één wordt opgehoogd, zodra de server een verzonden delta heeft verwerkt. Servers en ook alleen servers mogen versienummers ophogen.

History Hash

Een history hash wordt gebruikt om een staat van een wavelet uniek te identificeren. Dit wordt als volgt door de server berekend:

• Parsen mislukt (MathML met SVG- of PNG-terugval (aanbevolen voor moderne browsers en toegankelijkheidshulpmiddelen): Ongeldig antwoord ("Math extension cannot connect to Restbase.") van server "https://en.wikipedia.org/api/rest_v1/":): {\displaystyle HHv_0 = waveletNameToURI(waveletName) }
• Parsen mislukt (MathML met SVG- of PNG-terugval (aanbevolen voor moderne browsers en toegankelijkheidshulpmiddelen): Ongeldig antwoord ("Math extension cannot connect to Restbase.") van server "https://en.wikipedia.org/api/rest_v1/":): {\displaystyle HHv_n = SHA_{256}(DELTAv_{n-1} + HHv_{n-1})[0-20] }

Waarbij dus de 0e history hash geidentificeert wordt door zijn URI, elke opvolgende history hash wordt de afgelopen delta bij de vorige history hash opgeteld, hiervan wordt een SHA256 hash gegenereerd.

Meer over SHA op deze wikipedia pagina

Versturen van Delta's naar de Client

Zodra een Master Server veranderingen toepast op een Wavelet, stuurt hij een reeks gegevens door naar alle clinets van participanten uit de participantlijst, die op dat moment met de Master Server in verbinding staat.

Deze reeks bestaat uit:

• De toegepaste delta
• Het nieuwe versienummer
• De nieuwe History Hash

Versturen van Delta's naar de Server

Als een client eigen gegenereerde operaties heeft toegepast in een Wavelet, dan dienen deze verstuurd te worden naar de client in de vorm van een Delta, samen met het huidige versienummer van een Wavelet. Bij succesvolle overdracht, bevestigd de server deze Delta door:

• het nieuwe versienummer te sturen
• De nieuwe History Hash te sturen

Zolang de client nog geen bevestiging heeft ontvangen, mag de server delta's naar de client blijven sturen. De client moet aannemen dat de server zijn wijzigingen nog niet heeft doorgevoerd tot een bevestiging is ontvangen, en dient ondertussen ontvangen informatie zo aan te passen dat de Wavelet state synchroon blijft met de versie van de server. Concreet gezegd moet de client OT blijven toepassen op de ontvangen operaties en de lokaal opgeslagen operaties. De client mag totdat hij een bevestiging heeft ontvangen, geen delta's meer sturen naar de server.

Error Recovery

Als client-server communicatie faalt, de client en server moeten het eens worden over een gemeenschappelijke staat van de Wavelet, wanneer communicatie hervat wordt. Je "faalt" wanneer je een actie uitvoert waarvan niet gespecificeerd is hoe hij verwerkt moet worden. De client start de Recovery en stuurt een lijst met alle history hashes, die de client van die Wavelet bezit, de Wave ID én de Wavelet ID. Als de server bovenstaande informatie ontvangen, verwerkt en goedgekeurd heeft, stuurt hij de laatst herkende History Hash uit de ontvangen lijst(1), de meest recente History Hash(2), en een aantal delta's.

• Als History Hash (1) gelijk is aan History Hash (2), dan mag verdere communicatie hervat worden zonder extra herstel.
• Als History Hash (1) niet gelijk is aan History Hash (2) of

Als de server de door de client geleverde History Hashes niet herkent, dan moet de client de huidige staat van de Wavelet van de server ophalen.

Discussie

Probleem: Wat als je in een groep zit, en daarnaast toegevoegd bent als gewone gebruiker? 

Denk dat we dit in de implementatie specifiek moeten voorkomen, door bijvoorbeeld een controle uit te voeren bij het toevoegen van een gebruiker. Voornamelijk een server side issue 

Wat als je een losse participant hebt, die daarna nog eens wordt toegevoegd als deelparticipant van een groep? 
*Antwoord: Groups en participants zijn beide unieke participants (uit definitie) dus zal het geen probleem zijn als een toegevoegde losse participant tevens in een toegevoegde groep voorkomt. 

Wat is een participantlist? Is het een document? 
*We hebben besloten dat een participantlist is een array van strings(id's) is. 

Wat is de relatie tussen wavelets en documenten? Kan het zo zijn dat een wavelet in een wavelet zit? 
*Wavelets kunnen inderdaad in Wavelets zitten. Wavelets bevatten documenten en een participantlist. Wavelets zijn geen participantlist, dus moet een Wavelet ook een document zijn. 

Wave view is de verzameling van wavelets in 1 wave waartoe 1 bepaalde gebruiker toegang tot heeft. (Wave view wordt verder niet meer genoemd, waar is deze goed voor? "For the purposes of communication" ??) Wij denken dat ze het volgende onderscheid bedoelen: 
*De server heeft de complete "wave" 
*Elke gebruiker krijgt slechts alleen gegevens die relevant voor zichzelf zijn, vanuit privacy oogpunt. Dit wordt zijn "beeld" van de wave, de rest krijgt hij niet en is niet relevant voor hem. Dit is zijn "Wave view". Dit is tijd-formaat efficiënt en dus ook goed voor communicatiedoeleinden. Dit is tijd-formaat efficiënt en dus ook goed voor communicatiedoeleinden. 

Iedere participant krijgt een eigen wavelet per Wave, met zichzelf als enige participant, waarin participant-gerelateerde informatie bijgehouden wordt. (Clientside of serverside of beide?) 
*Dit lijkt ons serverside. De client is nooit te vertrouwen, dit lokaal bijhouden is te makkelijk exploitbaar. HAX 
*Het is wel handig om een lokale versie bij te houden zodat de client ook al kan waarschuwen en incorrecte bewerkingen kan tegenhouden, maar dit moet zeker niet de "last line of defence" zijn. 

We beslissen dan dat het serverside moet zijn, uit veiligheidsoverwegingen. Multi-clienten is ook in het voordeel hiermee. Deze wavelet is een datawavelet die "user-data" wavelet heet. 

Private reply is 1 wavelet waarvan de participantlist een subset is van de participantlist van de vaderwavelet (In de huidige Google Wave implementatie, kun je ook mensen buiten de participantlist van de vaderwavelet gebruiken) Als ik de specificaties goed heb begrepen is dit ook de bedoeling. It's a feature! Not a bug. 
*We beslissen hierbij dat in een private reply alleen participants uit de participantlist van de vaderwave toegevoegd mogen worden.

Bronvermelding

http://www.waveprotocol.org/draft-protocol-specs/draft-protocol-spec
http://www.waveprotocol.org/draft-protocol-specs/wave-conversation-model
http://www.waveprotocol.org/whitepapers/internal-client-server-protocol
http://www.youtube.com/watch?v=v_UyVmITiYQ
http://xmpp.org/rfcs/rfc3920.html