[Bitrepository-devel] Protokol-præciseringer

[Jun Petersen Yoneyama]

Hej

Er sanitycheck en debug mekanisme eller vil I også bruge den i produktionskoden og i den åbne kode til referenceimplementationen?

Det sidste lyder ikke rigtig i mine ører.
I princippet bør det kunne fungere alene ved at dekode XML beskeden. Kopier i JMS headeren er kun til for at gøre det nemmere at programmere.
Men benytter man sig af JMS headeren, så bør det i praksis være godt nok.
(Bortset fra de felter, der er nyttige for JMS/ActiveMQ)

Hvis vi alligevel skal sammenligne JMS headeren med XML, så synes jeg det er nemmere bare at tage det hele fra XML.

Men sanitychek under test/debugging er klart nyttig

Med venlig hilsen

Jun



-----Oprindelig meddelelse-----
Fra: bitrepository-devel-bounces at ml.sbforge.org [mailto:bitrepository-devel-bounces at ml.sbforge.org] På vegne af Kåre Fiedler Christiansen
Sendt: 24. juni 2011 13:23
Til: bitrepository-devel at ml.sbforge.org
Emne: [Bitrepository-devel] Protokol-præciseringer

Hej,

Ved implementationen af Get har vi identificeret følgende ting som vi
ikke synes er helt klare når vi skal implementere.
Nogle af dem er fordi den del af protokollen ikke er helt færdig, andre
mangler vi måske blot at tage stilling, eller skrive en stilling vi
allerede har taget ned.

Emnerne kommer i fire klumper.

=== Behandling af beskeder ved modtagelse ===

Når vi modtager en besked, er der nogle måder vi skal opføre os på, som
for nogle vist er aftalt, men jeg ikke er sikker på hvor er skrevet ned;
og hvor andre er noget hvor vi blot skal have taget stilling.

1. Modtagelse af beskeder hvor pillar IDs ikke svarer til os

Jeg tror det er vores aftale at de blot skal ignoreres, men er det
skrevet ned noget sted?

2.  Skal man sanityChecke de elementer der både findes i JMS headers og
beskeden. Hvad skal man gøre hvis de er forskellige? (CorrelationID,
BitRepositoryCollectionID, ReplyTo, To (kan sammenlignes med
destinations man lytter på), type)

Jeg synes det vil være en god idé at sanitychecke - men jeg er ikke
sikker på hvordan det skal håndteres.
Hvad vi skal gøre hvis checket fejler? Jeg foreslår vi blot logger en
fejl lokalt og fortsætter. Jeg foreslår at det blot er en anbefaling til
pillar, og ikke et krav.
Hvem "vinder" hvis headeren er uenig med beskeden? Jeg foreslår beskeden
altid vinder (dog ikke med "To" - den er jo allerede modtaget). Det
synes jeg vi skal gøre til et krav.

3. Hvad skal man gøre hvis der ikke er et correlationID i beskeden?

Ignorer? Generer et correlationID? Benyt JMS message ID? Jeg foreslår vi
anbefaler at man benytter JMS message ID men ikke gør det til et krav.

=== Svar med "fejlkoder" og alarmer ===

Her er vi vist ikke helt klar med specifikationen - men kan vi tage
nogle første her-og-nu valg?

1. Der er et fundamentalt problem lige nu, med at
IdentifyPillarsForGetFile ikke kan sende fejlkoder med i svaret. Det er
vist i modstrid med hvad vi har aftalt, da vi ønsker at pillars kan
svare selvom de ikke har filen, så klienter ikke skal vente på et
timeout.

2. Lige nu tror jeg det eneste sted der er en specifikation af mulige
fejl-koder er i Eld's proof-of-concept-fejlkoder i XSD'erne. Det ville
være godt at få et sted at vedligeholde en liste af hvad der er og
hvornår det skal bruges.
Tilsvarende med hvilke alarmer der skal sendes hvornår.

 * Her er en liste af potentielle "Negative svar" og alarmer vi har
identificeret
   * Potentielle negative svar på enhver besked
      * Ukendt BitRepositoryCollection
      * Uunderstøttede versioner (også alarm?)
      * Ugyldig XML (også alarm?)
      * Fejl i sanitycheck - se ovenfor (også alarm?)
      * Intet correlation ID - se ovenfor (også alarm?)
      * Intern pillar-fejl forhindrer behandling (også alarm?)
   * Potentielle negative svar ved IdentifyPillarsForGetFile
      * File not found
   * Potentielle negative svar ved GetFile
      * File not found
      * Del af fil requested men ikke understøttet
      * Ingen/ugyldig URL angivet til at levere fil på
      * Problemer med at uploade filen til den givne URL (også alarm?)

3. I hvilke beskeder skal man sende fejlkoder? Jeg forventer at en
fejlkode betyder at konversationen er afsluttet for den pillars
vedkommende, og de derfor ikke skal sendes i
"ProgressResponse"-beskederne, som indikerer status undervejs, men
derimod i "FinalResponse"-beskederne.

=== TimeToDeliver ===
Jeg tror vi har aftalt at time-to-deliver er optional, men hvis den angives er det den forventede tid før man kan begynde at levere - men er det skrevet ned nogen steder?

Vi har også snakket om at man kan give opdaterede estimater i ProgressResponse-beskeder. Men det kan på nuværende tidspunkt ikke sættes i beskeden.
=== Request af flere filer i én GetFile-besked ===

Det er noget vi har snakket om nogen gange, men jeg ved ikke rigtig hvor
vi står.

Er der et use case for det? Eller skal vi blot droppe understøttelsen
helt. Jeg tror det er mig selv der har foreslået det for at kunne
gruppere requests til at brunge offline-medier online, men det kan i
virkeligheden klares lokalt på en pillar - på SB tape pillar'en husker
vi filer der er requested, men genererer kun et job til at bringe dem
online med passende mellemrum. Det giver samme effekt.

Hvis vi skal understøtte det mener vi der er et problem i at der er kun
én URL i beskederne, så vi ved ikke hvordan man skal levere flere filer.

Hilsen
  Kåre



_______________________________________________
Bitrepository-devel mailing list
Bitrepository-devel at ml.sbforge.org
http://ml.sbforge.org/mailman/listinfo/bitrepository-devel