Hi Wendy, If a client accidentally dropped the connection and hopes to re-connect and receive the merge-patch events, would it make sense for the server not to send the first full-map event? It will save quite some effort that way.
Best, Xiao On Thu, Oct 16, 2014 at 9:52 AM, Wendy Roome <[email protected]> wrote: > 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 > >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
