On Mon, Jul 21, 2008 at 12:37:40PM -0700, Brock Pytlik wrote: >>>> I think we need a text file in the doc directory explaining how all this >>>> works. >>>> >>> How what works? >> >> Search. >> > Ok, I'll start on this once I've gotten the next webrev up.
I'll note that Brock reminded me on Friday that there's a decent-sized comment in indexer.py about what's going on. Turns out I'd completely skipped that file, which didn't help. So it may be pretty straightforward to move this text into its own file. > Basically, I view redundant information as a positive when it doesn't > cause problems. In this case, the project has two indexes, with two > different entry points for updating them, so adding the redundant > information that it's the client indexes that are being updated rather > than the servers seemed like a reasonable thing to me. And if both entry points were in the same class, that'd make sense to me. > It's what lies behind my parenthesis view, the naming of other files with > client_X server_X when X is also present. There's usually tension in the balance between the clarity and elegance of expression and the safety of redundancy. I seem to fall further towards the former than most, you more towards the latter than most. Though there certainly will be times when I'll prefer a bit more redundancy, I just think you're a bit too heavy-handed with it, and not allowing for a reader who doesn't need all the crutches. > It used to live in publish_package. I agree accept publish seems like the > right place. Indexing is now the last thing it does before sending the > published response to the client. In fact, it probably needn't happen before the package moves into the published state, either, but making that happen asychronously is beyond the scope of your change. > My idea was to make the string representations as clear as possible so that > if we traceback (not something that should happen, but certainly something > which can happen) the user has as much information as possible. If a higher > function has a better idea of what to do (like client.py for example) it > can catch the exception and add to the string representation, or just > ignore it all together. It can always grab self.cause out if it wants that > detail, but not the others. Fair enough. Thanks, Danek _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
