Let me clarify and understand the context a bit more.
On Thu, Oct 23, 2014 at 5:34 AM, Xiao SHI <[email protected]> wrote:
> 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.
>
>
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.
> We use an "event" field to encode the unique identifier of the resource
> 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).
>
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?
>
>
How would Solution 2 work?
Richard
> Best,
> Xiao
>
--
--
=====================================
| Y. Richard Yang <[email protected]> |
| Professor of Computer Science |
| http://www.cs.yale.edu/~yry/ |
=====================================
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
