Hi Wendy,
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
>
>
>
> 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=
> [email protected]>
> >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
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
