Subject: [alto] Incremental Update/SSE Key Design Issue 1: Event subscription name in SSE

From: Xiao SHI <[email-masked]>
Date: Thu, 23 Oct 2014 05:34:07 -0400

Hi all,

Wendy, Richard, and I are considering the incremental updates subscription
model for ALTO using Server-Sent Event (SSE) streams. In this model, the
client subscribes to an event stream, and the server push updates as events
via the stream.

We use an "event" field to encode the unique identifier of the resource
that the event should update, which should be a subset of {resource-id,
resource-parameters, input-parameters}. (The client also has the IRD in its
possession so that it can do certain look-ups).

We would like a __minimal__ unique identifier of each resource and each
resource object. One resource could have multiple objects, e.g. when the
"accepts" field is non-empty (i.e. they have input params), or they could
have filters etc. Below are the proposal solutions:

For full network/cost map objects, resource-id is sufficient.
object {
  ResourceID resource-id;
} NetworkMapEventName;

object {
  ResourceID resource-id;
} CostMapEventName;

For resource objects that have non-empty "accepts" field or filters (i.e.
input params) in the IRD, there are multiple solutions:

*Solution 1. put the the input params in the events field*
For  filtered network map objects, resource-id coupled with the pids for
the filter:
object {
  ResourceID resource-id;
  PIDName pids<0..*>;
  [AddressType address-types<0..*>;]
} FilteredNetworkMapEventName;

For filtered cost map objects, we need to identify the costmap objects and
the filter:
object {
  ResourceID resource-id;
  CostType cost-type;
  [JSONString constraints<0..*>;]
  [PIDFilter  pids;]
} CostMapEventName;

e.g. the event for a filtered network map would start with:
event: {"resource-id":"my-default-network-map", "pids":["PID2", "PID4"]}\n

*Solution 2. add the input params information as meta information for an
update.*
We put the merge-patch object with the meta information together to form
the update object:
object {
  ResponseMeta update-meta;
  JSONObject merge-patch;
} ALTOUpdate;

What do people think?

Best,
Xiao

---

From: "Y. Richard Yang" <[email-masked]>
Date: Fri, 24 Oct 2014 00:42:21 -0400

Let me clarify and understand the context a bit more.

> client subscribes to an event stream, and the server push updates as events
The model is that an ALTO client can subscribe to *multiple* ALTO
information resources, to avoid multiple HTTP connections, if we do not
want one connection per stream. Hence, we need the event field for
demultiplexing.

> that the event should update,
>

an "event" field => the "event" field, which is the field in SSE to
demultiplex the streams (to potentially different handlers at the client).
I feel that we need to solve the problem in both directions: first the
client indicates the data stream and then the server pushes.

> which should be a subset of {resource-id, resource-parameters,
> input-parameters}. (The client also has the IRD in its possession so that
> it can do certain look-ups).
>

>   ResponseMeta update-meta;
How would Solution 2 work?

Richard

-- 
-- 
 =====================================
| Y. Richard Yang <[email-masked]>   |
| Professor of Computer Science       |
| http://www.cs.yale.edu/~yry/        |
 =====================================