Just to clarify what I am advocating here is that we not require to syndicate the entire publisher's HTTP response but rather select the minimum fields and metadata needed to process the PUSH by the subscriber. Additional fields/data can be transmitted but would be outside the scope of the spec and thus allow for different hubs to provide additional value. So some hubs could offer the raw responses but not all would have to.
On Jun 7, 6:44 pm, Monica Keller <[email protected]> wrote: > 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.
