...
- Dataoverførelse af pakken Id1 via http:/a/b.data fra pillar 2
- Dataoverførelse af pakken Id2 via http:/b/c.data fra pillar 2
- Dataoverførelse af pakken Id3 via http:/c/d.data fra pillar 2
Spørgsmål og mulige udvidelser
- *Oprettes private køer dynamisk? *
I praksis kunne det være rart at vide hvor lang tid det tager at oprette/nedlægge en kø. Hvis det lang tid, giver det så mening, at etablere private køer? Hvis alternativet er, at oprette alle (SLA-) relevante kombinationer af klineter/pillars, etc. Det må vi teste. (Bemærkning: Besked fra 2a sendes på "Klient1 To Pillar2". Hvorfor ikke 'bare' "Pillar2"?) - *Forslag: Udvide den indledende forespørgsel på pillars, så der også returneres hvilke datapakker, der er til rådighed. *
Dette er nødvendigt for near-offline pillars, hvor der kan være forskellige klargøringstider pr. pakke. (Alternativt: At begrænse antallet af dataIDs til en pr. forespørgsel. - *Hvis listen af dataID er magen til den oprindeligt udsendte, kan man så undlade, at sende den med tilbage? (Se f.eks pillar2's svar foroven) *
- *Tæller offsett fra 0 eller 1? *
- Er det korrekt, at tokens angives med http og ikke https? Nej!
- *Er det ok, at droppe pillarIds i private køer? *
- Stiller det større krav til en pillar at den selv skal 'dele beskeden op i operationer'? (Pillar 1 svarer med to svar da det er et near-online system og den ved at Id2 ligger online og Id1 og d3 begge ligger offline)