On Fri, Jul 3, 2009 at 3:08 PM, Dimitri Fontaine<dfonta...@hi-media.com> wrote: > Your software seems to be better than a wiki, but its potential users are > expressing needs and bikescheding. I think you'd better accept both kind of > changes as long as it's not making your life much harder than you'd want. > Frankly, what URL looks better: > http://commitfest.postgresql.org/action/commitfest_view?id=2 > http://commitfest.postgresql.org/2009/07
We've definitely gotten to the "harder than I'd want" point at this point. > Oh, and while at it, I don't foresee that we would want the commitfest of > july 2009 to change its name but not the "semantic" URL pointing to its > management. Or if it's ever wanted, as has been said, have a look at Apache > Rewrite Rules system, it's made for supporting content being moved. > Something in the spirit of: > RedirectPermanent /2009/07 /2009/08 I humbly submit that it's insane to thing about editing httpd.conf every time somebody renames an object. The point here is to *reduce* the administrative burden of maintaining this thing. > While at it, I imagine that within a given commit fest, a single patch will > have a stable shortname, or if it comes to change, we could accept that the > URL too change: > http://commitfest.postgresql.org/action/patch_view?id=71 > http://commitfest.postgresql.org/2009/07/Synch_Rep > http://commitfest.postgresql.org/current/Synch_Rep > > Now, rather than following the names with apache setup, maybe you could add > something like some history tables tracking short name changes (maybe some > ON UPDATE trigger would do), so that referring to an older name would send a > HTTP 302 redirect to the new name URL? So, the good thing about the current system is that the URL *doesn't* change and you *don't* need complicated bookkeeping to remember every URL you've ever assigned to the thing to get it. I am well aware that it's possible to design a system that does this, but what benefit do we get out of it? Making it possible to tell what a URL points to without clicking on it, for those occasions when you're stranded on a desert island with a URL and no Internet access? There's a subtle and pernicious danger of the system you're proposing, too. If we regularly change the URLs that refer to certain objects, but compensate for that by remembering the whole history of URLs that have ever referred to that object, then there will multiple URLs that refer to the same object, of which all but one will contain WRONG information about what that link points to. The http://commitfest.postgresql.org/2009/07/Sync_Rep link, for example, might imply to someone that the patch is in the 2009-07 commitfest, but in fact it may well have been moved to the 2009-11, 2010-01, or 2010-03 commitfest, or we might have finally come to our senses and realized that it ought to be called "streaming rep" and rename it. It's true that the current URLs, without some sort of accompanying text, do not tell you what they point to. But no information can often be better than disinformation. > I'd like your work to be useful for all of us and appreciated to its real > value, and those changes well seem like user interface improvements rather > than basic structure or behavior questioning. I'd like that, too. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
