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.
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
On 10/15/2014, 00:32, "[email protected]" <[email protected]>
wrote:
>Date: Wed, 15 Oct 2014 00:32:56 -0400
>From: "Y. Richard Yang" <[email protected]>
>To: IETF ALTO <[email protected]>
>Subject: [alto] Incremental updates transport using SSE?
>Message-ID:
> <CANUuoLoY5tXsWg4mknQ0WsR43ZWVfDe=qb7xv1u0qa1zb42...@mail.gmail.com>
>Content-Type: text/plain; charset="utf-8"
>
>Dear all,
>
>Given the potential progress in incremental update messaging format (e.g.,
>merge-patch or tree-replace), it is time to consider the next item:
>transport. In particular, we want decoupling of update message format from
>transport: the payload can be carried by not only HTTP Patch, but other
>methods, say client pull using HTTP POST, or SSE.
>
>In particular, consider a design where an ALTO server pushes incremental
>updates to an ALTO client using SSE. How about the following straw-man
>mapping design, for client subscription and server push content
>indication:
>
>event name: ALTO resource-id
>
>id:
> if initial resource (full content), tag as full alto resource
> if new-tag_old-tag
>
>data: {
>data: "Content-Type": "application/merge-patch+json" | rfc6902 patch
>data: "Content":
>data: {
>data: <op object here, need escape to avoid ambiguity, i.e., no extra
>\ndata:>
>data: }
>data: }\n\n
>
>Make sense, by SSE experts?
>
>Richard
>
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
