Initial thoughts/questions...

[Jud Valeski]

Thanks for doc'ing these thoughts in a spec proposal type format;
really helps crystalize the thinking.

1) this feels primarily like a mechanism to allow user-facing
applications (e.g. an RSS reader-like thing/client-app) to present
"pings"/updates to said end-users. thoughts around machine-to-machine/
service-to-service usage?

2) on the subscriber side of things, HTTP PATCH vs. PUT... PUT feels
better, but admittedly, I'm not all that familiar with PATCH.

3) what format do POSTs to a registered subscriber come back in; diffs
or otherwise?

4) on the discovery side of things... my experience is that service
endpoints usually know a lot about a) eachother's existence, and b)
how to interact with eachother. therefore, dynamic discovery schemes
(for machine-to-machine... this differs a bit when a user is involved;
see #1 above) are generally overkill. at a minimum, maybe XRDS-Simple?

[Paul Jones]

Hi Jud,

On Tue, May 13, 2008 at 11:36 PM, Jud Valeski <j...@gnipcentral.com> wrote:

Thanks for doc'ing these thoughts in a spec proposal type format;
really helps crystalize the thinking.

1) this feels primarily like a mechanism to allow user-facing
applications (e.g. an RSS reader-like thing/client-app) to present
"pings"/updates to said end-users. thoughts around machine-to-machine/
service-to-service usage?

A lot of the initial implementation work I've been doing as I developed this was for service-to-service usage. I think the HTTP-style notification methods are going to be largely useful for service-to-service, whilst the XMPP mechanisms will be the ones that come into play for users.

2) on the subscriber side of things, HTTP PATCH vs. PUT... PUT feels
better, but admittedly, I'm not all that familiar with PATCH.

I actually see a  combination being the best approach with their use in the end. When it comes to "service-to-service" style communication, there are a few desirables that I see - low bandwidth, fault tolerance. Diffs obviously provide the way to make the data low bandwidth - especially since only small fractions of documents tend to change at a time. However, if a service is unavailable when an update arrives, this could get them out of sync. The way that I've been working around this internally is through the use of the ETag header. When an update is about to be performed, the source queries the destination with a HEAD, works out what content version they have, and then sends a diff (via PATCH) based on that. If there is no known version, it then falls back to a PUT.

3) what format do POSTs to a registered subscriber come back in; diffs
or otherwise?

So this is part of the discovery/negotiation - the subscriber registers how they want the update. In the context of the HTTP mechanism, this is provided as a mime-type of the diff. My intention is that a missing diff type would imply no diff being requested.
 

4) on the discovery side of things... my experience is that service
endpoints usually know a lot about a) eachother's existence, and b)
how to interact with eachother. therefore, dynamic discovery schemes
(for machine-to-machine... this differs a bit when a user is involved;
see #1 above) are generally overkill. at a minimum, maybe XRDS-Simple?

I intend to rework the discovery just slightly to make it XRDS simple compliant (it is quite close already - XRDS Simple just allows us to remove the HttpMethod attribute, as it already defines it). I actually see discovery as being fairly important The base details of the protocols don't change, but the support for various diff and notification methods will vary. I don't want to end up with a scenario where every consumer has to code specifically for a given producer - realistically, that would put us no further ahead than we already are.
 

Paul.