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

[Mikis Seth Sørensen]

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