[alto] Remaining issue of SSE

[Dawn Chan]

Hi authors of SSE and ALTOers in the working group,

According to the last ALTO WG meeting, we have a remaining issue about SSE. SSE now provides two services, the update stream service and the update stream control service. Update stream control service allows a client to remove resources or add additional resources. The issue is that when the client sends a “remove” request through the update stream control service, how will the server inform the client that the operation is successful or not.
When the client sends “remove” request to the server, response options are:
1. The server notifies outcome to the client in the HTTP response by using an HTTP response code.
2. The server notifies outcome to the client in an HTTP response by using an HTTP response code and also an update stream message.
Curren draft adopts option 2.

The question is:
Is it really necessary for the server to send a response in the update stream?

The motivation for the server to send a response in the update stream is that there might be the inconsistency between the process dealing with the update stream service and the process dealing with the update stream control service. So only sending an HTTP response code does not really stand for the real actions taken by the update stream service. However, personally thinking, such situations only indicate the misbehavior of the server rather than the misbehavior of the protocol. The server can design its own mechanisms to stay avoid such mistake. Thus, adopting option 1 is enough.
Do you support option 1? It would be great to hear your ideas.

Thanks,
Dawn

[Vijay K. Gurbani]

[... As individual ...]

Dawn: I prefer option 2 for the following reasons:

a) The "remove" request is sent through the update stream control
service, therefore it seems appropriate (and expected) to send a
response through the update stream control service as well.

b) I would rather not conflate the responses at the HTTP layer with the
responses that are pertinent to the entities processing the HTTP
bodies. Responses at the HTTP layer are needed to satisfy the HTTP
state machinery. Yes, they can act as hints to the entity processing
the HTTP body, but my philosophy in protocol design is to be as
explicit as possible. Such explicitness calls out for each layer to
be responsible for its transactions instead of inferring the state of
a transaction by some exogenous means.

Doing so may be a bit redundant, but decreases the ambiguity that is
the bane of protocol design, IMHO.

Cheers,

Post by Dawn Chan
Hi authors of SSE and ALTOers in the working group,
According to the last ALTO WG meeting, we have a remaining issue
about SSE. SSE now provides two services, the update stream service
and the update stream control service. Update stream control service
allows a client to remove resources or add additional resources. The
issue is that when the client sends a “remove” request through the
update stream control service, how will the server inform the client
that the operation is successful or not. From the last discussion, we
proposed two response options: When the client sends “remove” request
1. The server notifies outcome to the client in the HTTP response by
using an HTTP response code.
2. The server notifies outcome to the client in an HTTP response by
using an HTTP response code and also an update stream message. Curren
draft adopts option 2.
The question is: Is it really necessary for the server to send a
response in the update stream?
The motivation for the server to send a response in the update stream
is that there might be the inconsistency between the process dealing
with the update stream service and the process dealing with the
update stream control service. So only sending an HTTP response code
does not really stand for the real actions taken by the update stream
service. However, personally thinking, such situations only indicate
the misbehavior of the server rather than the misbehavior of the
protocol. The server can design its own mechanisms to stay avoid such
mistake. Thus, adopting option 1 is enough. Do you support option 1?
It would be great to hear your ideas.

- vijay
--
Vijay K. Gurbani / ***@nokia.com
Network Data Science, Nokia Networks
Calendar: http://goo.gl/x3Ogq