[Bitrepository-devel] Protokol ændrings forslag

Jonas Lindberg Frellesen jolf at kb.dk
Thu Mar 29 10:02:45 CEST 2012


Jeg synes, at du får GetStatus til at lyde som et heart-beat. Altså noget der med et givent interval står og spørger efter status udelukkende for at se, om de pågældende komponenter er i live.
Jeg havde forstået, at GetStatus skulle indeholde information omkring komponents tilstand, f.eks. "Har det fint", "Er ved at løbe tør for plads", "Har ikke kritiske problem XXX", og lignende. Altså ikke blot fortælle om en komponent findes, men også fortælle om hvorledes den har det.


Med venlig hilsen
Jonas
________________________________
Fra: Kim Teglgaard Christensen [ktc at statsbiblioteket.dk]
Sendt: 29. marts 2012 08:35
Til: Jonas Lindberg Frellesen
Cc: bitrepository-devel at ml.sbforge.org
Emne: Re: [Bitrepository-devel] Protokol ændrings forslag

Det var umiddelbart tanken at have et string element i GetStatusFinalResponse indeholder en menneskelig læsbar beskrivelse af komponentens status. ResponseInfo elementet mener jeg helt klart skal holde samme betydning som i alle andre beskeder, altså fortælle hvordan operationen gik med nogle veldefinerede muligheder (ResponseCode) og en mere fri tekst streng.

Min første tanke med rød/gul/grøn lys var:
Grønt: når komponenten har svaret på den sidste besked.
Gul: hvis komponenten ikke har svaret de sidste [1 : n] requests.
Rød hvis komponenten ikke har svaret de sidste ]n : inf[ requests
n skal så være en konfigurations option.

Men det holder tanken ikke helt hvis en pillar kan sende en status tilbage med at "jeg har det skidt" - til det mangler vi en farve - og muligvis en måde "nemt" at afkode det.

I øvrigt vil jeg give Jonas ret, der er ikke ophold mellem Identify og det egentlige request.

Mvh Kim

On Wed, 2012-03-28 at 15:16 +0000, Jonas Lindberg Frellesen wrote:
Ideen om en ’WARNING’ type i ResponseCode kan jeg rigtigt godt lide. Den vil omfatte diverse problemstillinger i forhold til GetStatus.

Jeg læste det bare som om, at GetStatusFinalResponse ville indeholde et specifikt felt til status beskeden, som skulle være den eneste status besked.

Hvis det var tilfældet, så ville det være utroligt svært at lave den der ’grøn/gul/rød’ liste af lys i GUI’en, da man så ikke kunne identificere forskellen på succes, advarsel og fejl.





Mht. til 3 og 4, så lyder det som en ændring af besked flowet i forhold til de andre klienter.

Der er ikke en pause mellem identifikation og operation, hvor brugeren kan give input til hvilke steder operationen skal foregå. Dette skyldes bl.a., at det ikke kan kræves, at de pågældende contributers skal have en permanent destination.

Vi plejer altid at lave hele besked flowet på en gang. Altså først definere hvilke pillars (i dette tilfælde contributers) der skal bruges, derefter identificere hvilke af pillars der findes, og så udføre operationen på de udvalgte pillars (og ignorere de andre).



Jeg så hellere, at man gav en liste af contributers, som man ville høre status på, og derefter kun udfører operationen på de pågældende contributers (altså efter identifikations fasen, hvor man identificere alle tilgængelige contributers). Altså ikke udfører hele besked flowet på hver enkelt contributer eller have et bruger-input stadie mellem identifikation og operation.



Derefter giver man farve til de pågældende contributers afhængig af deres svar, f.eks. fejlet identifikation => rød, fejl i operation => orange, ’WARNING’ i operation => gul, og OPERATION_SUCCESS => grøn.





Med venlig hilsen

Jonas



Fra: bitrepository-devel-bounces at ml.sbforge.org [mailto:bitrepository-devel-bounces at ml.sbforge.org] På vegne af Mikis Seth Sørensen
Sendt: 28. marts 2012 16:30
Til: List for the Bitrepositorys developers
Emne: Re: [Bitrepository-devel] Protokol ændrings forslag




Se min forklaring nedenfor:





1. Vi har en liste af StatusContributers defineret i CollectionSettings.


2. For at finde ud af hvem der er online og samtidig finde de destination den efterfølgende request skal sendes til, broadcastes en IdentifyRequest (På samme måde som for andre operationer).


3. Når Identification fasen er færdig (alle har svaret eller vi har fået en timeout) er online status af 'StatusContributers' nu kendt (grøn/rød lys liste i GUI'en).


4. Hvis klienten er interesseret i mere detaljeret informationer kan den nu spørge individuelle komponenter om status via. GetStatusRequest. Det kan være at en bruger i webGUI'en klikker på en bestemt komponent.


5. En komponent skal ved modtagelse af en GetStatusRequest sende en ProgressResponse, hvis dette er mandatory ifølge CollectionSettings. ResponseInfo kan her være 'Starting to generate status'.


6. Komponenten sender en FinalResponse med den detaljerede status (som ikke nærmere defineret tekst streng).





ResponseCodes er fællesmængden af muligheder, så det vil altid være et subsæt der skal bruges for de enkelte operationer. Jeg mener ikke vi skal lave et rigt sæt af  StatusResponseCodes, men måske skal vi have en warning type ResponseCode, hvis komponenten som sådan kunne gennemfører operationen, men der er nogle ting man potentielt skal kigge på.





Mvh


Mikis




From:Jonas Frellesen <jolf at kb.dk<mailto:jolf at kb.dk>>
Reply-To: List for the Bitrepositorys developers <bitrepository-devel at ml.sbforge.org<mailto:bitrepository-devel at ml.sbforge.org>>
Date: Wed, 28 Mar 2012 16:02:00 +0200
To: List for the Bitrepositorys developers <bitrepository-devel at ml.sbforge.org<mailto:bitrepository-devel at ml.sbforge.org>>
Subject: Re: [Bitrepository-devel] Protokol ændrings forslag





Øhh… Lige et spørgsmål.

Hvorfor skal man identificere sine contributers før man efterspørger deres status?

Det virker bare overflødigt, da den i dette tilfælde har næsten samme formål som selve status beskeden.

Derudover får vi også Component ID’erne i CollectionSettings, så der er ikke noget problem angående, hvem der egentligt er contributers. Kun om de pågældende contributers er villige til at fortælle om deres status.




Og hvad betyder en ’ProgressResponse’ i forhold til en status besked?

Vil det ikke bare være en besked, der siger: ’jeg går i gang med at undersøge, hvordan jeg har det’?



Skal der i være en ResponseInfo med på den? Og i så fald, hvilke svarmuligheder giver det mening at kunne levere?

F.eks. ’Fejl! jeg kunne ikke finde ud af, hvordan jeg har det’? Det giver ikke mening, at give de fleste ResponseCodes med i svaret.

Det egentlige svar, som er interessant, finder man jo i ’status’ feltet.





Det er nok det forkerte forum at stille sådanne spørgsmål, da det i virkeligheden er rettet imod arkitekturen af besked-workflowet.



Men ud fra den valgte arkitektur lyder det meget fornuftigt.

Dog ville jeg foretrække, hvis svaret var mere som en ’ResponseInfo’, altså med både en læsbar streng og en fast defineret svar-kode (ligesom ResponseCode).

På den måde vil man kunne lave et bedre interface, som baserer sig på den pågældende svar-kode.





Med venlig hilsen

Jonas



Fra:bitrepository-devel-bounces at ml.sbforge.org<mailto:bitrepository-devel-bounces at ml.sbforge.org> [mailto:bitrepository-devel-bounces at ml.sbforge.org] På vegne af Asser Schrøder Femø
Sendt: 28. marts 2012 14:57
Til: List for the Bitrepositorys developers
Emne: Re: [Bitrepository-devel] Protokol ændrings forslag




+1 her også. Lyder fornuftigt!



Fra:bitrepository-devel-bounces at ml.sbforge.org<mailto:bitrepository-devel-bounces at ml.sbforge.org> [mailto:bitrepository-devel-bounces at ml.sbforge.org] På vegne af Mikis Seth Sørensen
Sendt: 28 March 2012 14:55
Til: List for the Bitrepositorys developers
Emne: Re: [Bitrepository-devel] Protokol ændrings forslag




+1





Mikis





From:Kim Teglgaard Christensen <ktc at statsbiblioteket.dk<mailto:ktc at statsbiblioteket.dk>>
Reply-To: List for the Bitrepositorys developers <bitrepository-devel at ml.sbforge.org<mailto:bitrepository-devel at ml.sbforge.org>>
Date: Wed, 28 Mar 2012 14:53:15 +0200
To: "bitrepository-devel at ml.sbforge.org<mailto:bitrepository-devel at ml.sbforge.org>" <bitrepository-devel at ml.sbforge.org<mailto:bitrepository-devel at ml.sbforge.org>>
Subject: [Bitrepository-devel] Protokol ændrings forslag





Hej Folkens

Da GetStatus client + service er ved at være i støbeskeen er tiden kommet til at kigge på beskederne vedrørende getStatus. I den forbindelse har jeg været ved at kigge lidt på det og har et par forslag.

IdentifyContributorsForGetStatusRequest/Response ser rimeligt ud, hvilket efterlader GetStatusRequest/ProgressResponse/FinalResponse.
Da status gerne skulle være rimeligt simpelt, ser jeg ingen grund til at have en kompleks struktur til resultatet, ej heller at have muligheden for at uploade resultatet.

Jeg forslår derfor at lave et enkelt element i FinalResponse indeholdende en streng, hvor i en status kan skrives som en menneskelig læsbar streng. Derved bliver Request beskeden temmelig simpel, og ProgressResponset skal ikke indeholde andet end contributor ID'et.

I samme omgang har jeg tænkt over om det ikke ville give mening at ændre samtlige beskeder til at have et ComponentID, sådan at det kan ryge op i Message elementet i XSD'en og vil erstatte PillarID og Contributor i de forskellige beskeder. Det vil også passe ind med at vi skal have permissions pr komponent.

Hvad siger i til de ovenstående ændringsforslag?

Mvh Kim







-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ml.sbforge.org/pipermail/bitrepository-devel/attachments/20120329/884bf40e/attachment-0001.html>


More information about the Bitrepository-devel mailing list