I would like it to be very easy to consume arbitrary formats. The question is how much should the hub should normalize the response from the publisher to help the subscribers ? Is it a dumb rebroadcaster which maintains fidelity of the publisher's response or is it a smarter agent which validates before re syndicating ?
I was leaning towards the latter Producing a more RESTful PUSH specifying the method: POST, PUT, DELETE, PATCH For example if the publisher returns a 404 the hub is not necessarily going to send that to the subscribers. If the publisher returns the same resource that also would not be sent to the subscribers. If the publisher returns a 410 then we can just use HTTP DELETE or the X-Method-Override to pass it in. Overall I prefer the model where the hubs do most of the work. Potentially offering additional services such as translation of formats or malware detection so I would rather not make it a requirement to re transmit the original HTTP response in its entirety and focus on the specific headers needed. We should probably prototype the alternatives and let several developers try and handle the pushes On Mon, Jun 7, 2010 at 1:31 PM, Martin Atkins <[email protected]>wrote: > On 06/07/2010 09:32 AM, Brett Slatkin wrote: > >> >> Generally I agree with this approach. The needs of a self-describing >> document/payload are different than those of a document/payload that >> requires the headers for correct interpretation. The same applies to >> HTML and hAtom, where the hub link would be in the html<head> and the >> headers are mostly irrelevant. This also has an effect on security, >> where the generic HTTP version must preserve the fidelity of the >> payload's headers, whereas the self-describing document can drop them. >> > > To be fully general, the notification payload could be an HTTP response > encapsulated in an HTTP request. That way the subscriber will get all of the > HTTP headers exactly as returned by the topic URL, and most importantly the > subscriber will get the HTTP status code which will allow the subscriber to > detect, for example, a 410 Gone response indicating that the resource has > been permanently removed. > > The challenge with this approach, of course, is that some HTTP frameworks > may not provide a convenient way to parse an arbitrary payload as an HTTP > request, and it complicates the common case of just getting notifications of > changes to the content. > >
