On Thu, Mar 11, 2010 at 02:46:15PM -0600, Shawn Walker wrote: > On 03/11/10 02:40 PM, [email protected] wrote: > >Hey Shawn, > > > >Thanks for taking a look at this. > > > >All of these points seem a bit orthogonal to the original change, but > >I'm happy to include them since they seem likely to cause either > >tracebacks or other annoying issues. > > Yeah, sorry about that. But I figured they should at least be noted. > It doesn't matter to me if they get fixed as part of this or as > something else.
I don't think you need to apologize for finding bugs in the code. :) > >I should be able to delete this exception handler entirely, no? Out of > >curiosity, what does the caller of get_catalog1 expect in this situation > >now? Should the underlying code continue to treat a 304 as a permanent > >failure? > > Oh, right, that would work too. At the moment, the conditional > retrieval logic isn't used at all because of the depot catalog > rebuild cases. However, I'd like to revisit that decision and see > if we can't reinstate the conditional retrieval using different > logic at least for some parts. Ok. It looks like the 304 was always considered a permanent failure. I've removed the extraneous exception handler. If you decide to go back to using conditional retrieval, you'll probably want some kind of API/Catalog exception that informs the caller that the requested object wasn't modified. I'm trying to keep TransportExceptions opaque to everything except the transport, which is why we had wrapped the exception in that code originally. I've got a new webrev for you now: http://cr.opensolaris.org/~johansen/webrev-15119-2/ Thanks again for looking at this. -j _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
