On Wed, Aug 12, 2009 at 7:18 AM, Elaine Ashton<[email protected]> wrote:
> What makes you believe that breaking them either today or in 2 years is
> going to be met with a discernibly different response?
Why do you presume they will break? What actions will cause this
breakage? I believe your assumptions are flawed, and therefore your
conclusions are suspect.
The only disruptive user action I can foresee is that of actively
deleting a page. And, if a page is deleted, it is proper to give a
"not found" error. The other cases of moving/renaming/merging all
should be easily and routinely handled by the wiki engine's page
history tables.
>>> Links change constantly and we can't control who points to what in
>>> various media
Yup, which is why reasonable content management systems keep track of
content naming changes - so the redirects from oldest to old to new to
newer can be handled automatically. The key is to *NOT* worry about
it, but let the design of the system handle it FOR you.
> do little but gripe and sling insults.
I thought this was "user requirements gathering", "beta testing" and
"usability feedback"; if all you see it as is "gripes and insults",
then we're screwed. Gee, the support job is so much easier now that
we've gotten rid of all the users!
> I AM thinking of the end users as if we would do a URI rewrite for 10-20,000
> pages, this would entail the server scanning /every/ rule to match against
> before finally serving up the page. In the battle of glacial server vs.
> broken link on a zippy server, the zippy server wins.
Have *you* actually tested this and found any measurable performance
degradation? The rewrite algorithm should be a "fail fast" one that
doesn't impact the normal URLs:
If the URL begins with "/os/" then
# we have an old url that needs to get special handling
go to the slow, gross table search
else
go directly to the wiki
In fact, there must already be an equivalent set of rules there *now*
that redirect old pages to their parent collective's home page, so
your objection is somewhat irrelevant.
Nevertheless, you are ignoring a middle ground - redirecting only a
subset of "high profile" urls. As I said earlier in this thread:
The website conversion is being done by automated tools, so the set of
redirects can be known exactly at migration time. The list could even
be pruned by community facilitators before it is deployed if you are
concerned about having "too many" - I'd bet there are only a few
"static urls" in each community that need to be kept forever.
If you treated us idiots with a little more respect, you'd find that
many of us would be willing and able to help with this process. In
fact, I'd go further and say that 100% of the ones who are both
knowledgeable about the problem and have URLs that need redirection
will gladly step up and provide lists of those URLS; the others
probably don't need /any/ redirects.
-John
_______________________________________________
website-discuss mailing list
[email protected]
