[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PaceServiceError comments



On Wed, Jun 23, 2004 at 02:52:48PM +1000, Eric Scheid wrote:
> 
> A couple of questions:
> 
> (1) What should happen if the fetching of the feed is distinctly separated
> in time from the validation (and hence error reporting)?
> 
> If I update my feed at 1:00pm, somebigfeedproxy fetches it at 1:05pm in a
> huge batch job along with hundreds of other feeds elsewhere, I update it
> again at 1:10pm, somebigfeedproxy finally gets around to processing the
> fetched data at 1:15pm ... should somebigfeedproxy do a quick HEAD to see if
> it's changed in the meantime? Do I want to be notified of errors which I've
> already corrected?

Your questions are good. I'd say that reporting an error should include a
body in the request. That body can specify the etag of the feed which had
the error in it. The server could say, "hunh. that's not the current etag.
they're referring to an old feed. I don't care. <punt>"  Of course, the
server policy could also retain it.

Having a specified body also means that you can pass along specific
information about what went wrong. Within the WebDAV DeltaV specification,
we came with with XML tags that corresponded to specific error situations.
Thus, you can "prefill" a bunch of error cases by declaring certain tags.
If a client figures out a new error condition that is not covered by an
existing that, then they could use an atomerr:human-readable tag and just
dump some flat text into the appropriate part of the request body.

> (2) What if I've subscribed to a feed, and have fetched valid feeds so far,
> but now find that the data pulled is not valid (and I got a HTTP 200 OK
> status code) ... if I can't find the service.error endpoint in the junk I've
> just fetched (including headers), is it permissible to use the service.error
> endpoint from the last valid fetch?

Bah. Very complicated.

I believe the right answer is to send an ERROR request back to the feed
URI that caused the error. You already have the URI -- no need to try and
figure out something else. And the ERROR method describes exactly what
you're trying to do: report an error. It isn't a GET of the feed, and
certainly not some no-semantic POST. It is reporting an error to *THAT*
feed, and <here> is the body describing the problem.

Cheers,
-g