[Bitrepository-devel] response / complete messages 1. optional / required 2. better names?

[Kåre Fiedler Christiansen]

Hej,

Jeg har ikke fået svaret på denne, men da jeg ikke er til mødet i morgen, vil jeg gerne lige give mit besyv med.

Jeg støtter 100% Bolette forslag om at omnavngive beskederne.

Desuden er jeg af den holdning at et forventet message flow for f.eks. GetFile er følgende (med ny terminologi):

1. Klient sender IdentifyPillarsForGetFileRequest
2. Pillars sender alle IdentifyPillarsForGetFileResponse
3. Klient sender GetFileRequest til udvalgt pillar
4. Pillar sender 0..* GetFileStatus-beskeder
5. Pillar sender GetFileResponse

Som det fremgår af skridt 4 mener jeg <Op>Response-beskeder *er* optional. Men jeg er enig med Mikis i, at vi ikke skal beskrive beskeder som "optional for klienten". Det skal bestragtes som et fejlscenarie hvis der ikke kommer noget svar - men fejlscenarier skal naturligvis håndteres korrekt.

Hilsen
  Kåre


--
Kaare Fiedler Christiansen - Software developer
THE STATE AND UNIVERSITY LIBRARY,
Universitetsparken 1, 8000 Aarhus C, Denmark.
Phone: +45 89462036
________________________________________
Fra: bitrepository-devel-bounces at ml.sbforge.org [bitrepository-devel-bounces at ml.sbforge.org] På vegne af Mikis Seth Sørensen [mss at statsbiblioteket.dk]
Sendt: 6. maj 2011 11:19
Til: bitrepository-devel at ml.sbforge.org
Emne: Re: [Bitrepository-devel] response / complete messages 1. optional / required 2. better names?

Jeg syntes man skal passe på med at sige at response og complete
meddelelser er optional. Disse meddelser er mandatory at sende fra benene,
og klienterne kan forvente at modtage dem som udgangspunkt.

MEN, som vi har snakket om tidligere har vi nogle generalle
asynkronitetets/robusthedsbetragtninger der siger at man ikke nødvendigvis
modtager en svar indenfor en bestemt tid (hvis nogensinde), så man skal
lave sine klienter robuste over for disse situationer.

Dvs. der er en plan A/normal kommunikation man skal implementere efter
(alle meddelelser når frem inden for en vis tid) + evt. robusthedshensyn.
Jeg mener det er vigtigt at skelne mellem normal workflows og
'alternative/specielle' situationer (som ikke derfor nødvendigvis er
deciderede fejl situationer).

~Mikis

On 5/6/11 11:07 AM, "Bolette Ammitzbøll Jurik" <bam at statsbiblioteket.dk>
wrote:

>  Designdiskussion flyttet fra videomøde til mailing liste:
>
>Punkt 1
>Er vi enige om at
>- Response messages are optional?
>- Complete messages are optional from the client point of view,
>mandatory from the pillar point of view?
>
>Hvis vi er enige skal jeg nok opdatere i hvert fald Put og Get på wikien.
>
>Punkt 2 (message names again)
>If the Complete message contains the response (either directly or as
>information that the operation has been completed and possibly an
>address) and the Response contains optional progress information along
>the way, are these good names? I think they will be difficult to
>explain, when presenting this protocol. I suggest the following names
>
>- Identify...for<op>Request
>- Identify...for<op>Response
>- <op>Request
>- <op>Status (instead of <op>Response) (please help me come up with a
>better name)
>- <op>Response (instead of <op>Complete)
>
>I know that the reason for calling the first response Response was that
>it made sense as a response or an acknowledgement of the Request, but as
>we have opened up for multiple response messages and then a final
>complete message the request->response model doesn't quite fit. An
>alternative would be to combine Response and Complete. This would mean
>that we have a somewhat complicated Response message with a lot of
>optional content, and a requirement of at least one such Response
>message with the content of the complete message required.
>
>Let me know what you think.
>/Bolette
>
>_______________________________________________
>Bitrepository-devel mailing list
>Bitrepository-devel at ml.sbforge.org
>http://ml.sbforge.org/mailman/listinfo/bitrepository-devel


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