Richard,
Wonderful! So let¹s generalize it with the following event types:
application/alto-networkmap+json // Full network map
application/alto-networkmap-merge-patch+json // JSON merge-patch for a
network map message (new)
application/alto-costmap+json // Full cost map
application/alto-costmap-merge-patch+json // JSON merge-patch for a cost
map message (new)
This could be extended to the proposed PID-property map service, if that is
accepted.
I dropped endpointcost and endpointprop because those are not full maps.
They return costs or properties for the endpoints specified by the client. I
don't know what "incremental update" would mean in that case. Any ideas?
It's possible to extend this to the directory as well. But I hesitate to do
that because what happens if the update changes the incremental update
resource? Also, if a server has linked directories, it wouldn¹t cover
changes to the linked ones. But again, if you can define how that would
work, go for it.
The IRD entry for this update service could have media-type
text/event-stream, the MIME type for SSE, and an "event" capability with a
list of the event types this stream supports. For example,
application/alto-networkmap+json
application/alto-costmap+json
application/alto-costmap-merge-patch+json
would mean that stream sends merge-patch cost map updates as the are
available. It also sends new network maps when they change, but it always
sends full maps, not merge-patch updates.
We could also define a filtered update service. Same idea, except that it is
a POST request, and the client sends a list of the event types the client is
willing to accept.
There are a few additional requirements, such as if a resource's event list
has a merge-patch type, it MUST have the corresponding full-map event as
well. The server MUST send a full map event before it sends the first
merge-patch event. And for the filtered service, a client MUST request the
full map event if it wants the merge-patch event.
- Wendy
From: "Y. Richard Yang" <[email protected]>
Date: Wed, October 15, 2014 at 17:27
To: Wendy Roome <[email protected]>
Cc: IETF ALTO <[email protected]>
Subject: Re: [alto] Incremental updates transport using SSE?
On Wed, Oct 15, 2014 at 4:09 PM, Wendy Roome <[email protected]>
wrote:
> I like SSE as well. But I suggest using the event field for the data type.
> That means we have two events: application/alto-costmap+json and
> application/merge-patch+json.
>
Interesting alternative design. Always preferring a solution that is
general, I would prefer an SSE design that handles general cases; for
example, ALTO server may output more media types such as
alto-directory+json, alto-networkmap+json, alto-costmap+json,
alto-endpointprop+json, and alto-endpointcost+json. The design should handle
all such cases and potential new media types.
Make sense?
Richard
> For an application/alto-costmap+json event, the data is JSON for a Cost
> Map response message, as defined in RFC 7285. To handle this event, the
> client throws out any previous cost map data and starts over from scratch.
>
> For an application/merge-patch+json event, the data is a JSON merge-patch
> update to the previous cost map data. The client applies that patch.
>
> When a client initiates the stream, the server MUST send an
> application/alto-costmap+json event as the fist message. Subsequent
> messages are application/merge-patch+json events. The server can also send
> another application/alto-costmap+json event, if the changes are so
> dramatic that that is easier. E.g., suppose the network map changed and
> renamed the PIDs.
>
> Note that this method does NOT need version tags for cost map versions.
>
> So a stream would look something like:
>
> event: application/alto-costmap+json
> data: {"meta": {...}, "cost-map": {"PID1": {...}}
>
> event: application/merge-patch+json
> data: { json merge-patch }
>
> - Wendy Roome
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
