On Fri, 2005-07-08 at 22:40 +0100, Timwi wrote:
Rob Lanphier wrote:
On Fri, 2005-07-08 at 20:56 +0100, Timwi wrote:
Article titles with a slash in them, such as [[History/edit]] if anyone ever wanted to create it, could be encoded using a double-slash:
http://en.wikipedia.org/History//edit http://en.wikipedia.org/History//edit/edit http://en.wikipedia.org/History//edit/history
This is less alienating than "%28" for parentheses or "%2C" for commas, but of course one could always use "%2F" for slashes for consistency.
I'm not sure if there's a specific prohibition of this practice in any spec,
No, there isn't.
Ok, that's good. What about the ramifications for relative URL handling in RFC 2396? http://www.ietf.org/rfc/rfc2396
I haven't found any immediate problems, but it would take me a while reading through the BNF to figure out if there are places where it breaks.
Not that it's a huge deal if relative URLs don't work, since MW can always just stick to absolute references, but its one area where things can go wrong.
but it does fight typical conventions, which is kind of a bad thing. For example, it appears that Apache throws away extra slashes, as can be seen here: http://apache.org///foundation////faq.html http://apache.org/foundation/faq.html IIS seems to do the same thing: http://www.microsoft.com////windowsserversystem///default.mspx
I assure you that Apache does not throw away extra slashes. I have already done the necessary programming to do URLs such as those I have mentioned. The examples you mentioned don't say anything about the webservers themselves because both URLs are obviously mappings to a filesystem (whether virtual or not); it is that filesystem that throws away the extra slashes (which you can easily test: Both Linux and Windows allow you to put double-/ resp. double-\ in a path and it won't complain).
Compare: http://www.livejournal.com/manage/index.bml and http://www.livejournal.com/manage//index.bml
They show the same page because the path is a mapping to a filesystem, but the pages are different because the individual strings on it are retrieved from codes that are based on the path. Those codes contain only single slashes, so the second page is missing those strings. This clearly shows that it's the filesystem and not Apache that "throws away" double-slashes.
Ok, that's good.
Still, I maintain that assigning unique semantics to "//" versus "/" when used in that part of a URL doesn't have a lot of precedent, which also means that there's probably a lot of places it can break. I admit that's a vague criticism, but I just have a bad gut feeling about going down that road.
Mixing subpages into the action namespace seems like a bad idea. Arguably its worse when its only the exception, because that means it'll be something that will always need to be accommodated, but rare enough that its often forgotten.
I don't understand what you're saying here. I'm not "mixing" anything. The rest doesn't seem to make any sense. Can you rephrase this?
First, let me quote again the part of your proposal which I was responding to, and try again with a clearer response:
URLs such as http://en.wikipedia.org/Pagename/subpage would then redirect to http://en.wikipedia.org/Pagename//subpage and you could still type a single slash as long as the subpage doesn't happen to be "edit", "history", or any of the other magic words.
Let's say there's an article called "Particles", with a sub-article "Atom".
The "Particle" article would be: http://en.wikipedia.org/Particles
...and the Atom subarticle would be: http://en.wikipedia.org/Particles/Atom
Now lets say that a future version of MW allows output of the history of any page in Atom form, with "/Atom" designating the output.
So, after the upgrade, what used to be a valid reference to the Atom article is now an atom feed. The new URL to the article is: http://en.wikipedia.org/Particles//Atom
But wait, we already committed to not break incoming links. Crap...now we have to choose a name for every new action that doesn't overlap with any existing subpage.
This is what I mean about keeping namespaces separate ("namespace" in the general sense, not the MediaWiki specific "Foo:Bar" sense). I would much prefer there be a syntactic way of distinguishing between a subpage and an action that always works, even on Tuesdays ;-)
In the spirit of putting the action at the end, perhaps this syntax would work: http://en.wikipedia.org/Pagename?action=edit http://en.wikipedia.org/Pagename?action=history
Of course it would "work", but it's not what I want because "?action=" is a pain to type.
...but it's far less ambiguous, and it's clear that it's an action performed on article "Pagename", rather than a page of its own.
Rob