Monastery URLs don't need double slashes!

[chip]

It's a bit of a pet peeve of mine that for some reason everyone wants to put double slashes after the scheme in all kinds of URLs, when the only reason there is a double slash in some (not all!) http URLs is to flag the presence of a hostname before the path.

So the "id://12345" URLs having a double slash is not only useless, it's unnecessarily confusing. When you make up your own scheme ("id" in this case), you can do whatever you want after the colon. That's why "news:alt.usenet.kooks" and "mailto:chip@pobox" are legal.

So in the Monestary, URLs "id:12345" and "cpan:DBI" would be just fine ... if only our esteemed vroom would support them. (And they'd be easier to type, too.)

    -- Chip Salzenberg, Free-Floating Agent of Chaos

[footpad]

Actually, if you take a look at RFC 2396, which outlines the structure of a URI, you'll note that mailto: and news: are exceptions to the general rule regarding schemes. While Section 3 does say "The URI syntax does not require that the scheme-specific-part have any general structure or set of semantics which is common among all URI", I think you'll notice that the next sentence offers a bit of advice:

However, a subset of URI do share a common syntax for representing hierarchical relationships within the namespace. This "generic URI" syntax consists of a sequence of four main components:
     <scheme>://<authority><path>?<query>
each of which, except <scheme>, may be absent from a particular URI.

Since the prefix tags are meant to fit within our own namespace, I don't see any harm in keeping them consistent with the majority of generally-supported schemes listed in Section 1.3.

After all, if you're used to typing "://" as part of your UR(I|L|N)'s, why invent an alternate syntax for our local schemes? Consistency can be a good thing, after all.

So, I vote 'No.' Sorry...

--f

P.S. BTW, Appendix B of that same RFC offers an interesting discussion for anyone trying to use regular expressions to parse URI's. Of course, I imagine that URI-1.17 (among others) would be helpful, too. :-)

[chip]

Well, I think the author of that RFC was observing a pattern, not prescribing a rule. Rules should only be applied where they are in some way beneficial; and frankly I see no benefit to using three punctuation marks where one would suffice.

As Larry said once: "It's not really a rule; it's more of a trend."

UPDATE: Note also that the RFC shows (just below the bit that you quoted) that the "//" punctuation only appears before an "authority" (e.g. hostname). For example, the "file:" URI scheme doesn't use "//" for URIs of filenames that have no specified hostnames. Therefore, even the given RFC doesn't call for universal use of "//".

    -- Chip Salzenberg, Free-Floating Agent of Chaos

[demerphq]

I once saw an interview with T. Berners-Lee the author of the original, and most subsequent, spec(s) for URLs/URIs (they started with the WWW in RFC 1630 ). When asked if he had regrets he laughed and said (paraphrased to the best of my recall)

Yes. I really wish I hadn't made urls start with a double backslash.

Yves / DeMerphq
--
This space for rent.

[tye]

When (if?) patching gets rolling a little more smoothly, I'd hoped to update the scheme to allow things like [id://6364&usersearch=tye|Tye's nodes] and perhaps [/?op=randomnode]. Making "//" mostly optional could be rolled in as well.

One problem with "//" being optional is that you could no longer use [] to link by title to a node whose title was like "this: that" where "this" was one of the many link keywords (the list of which keeps growing). Though this seems a very minor problem and you already can't link to a node titled "id:// should just be id:" that way, so I'd probably just want to add a [title:...] form as well.

It'd also be nice if you could use URL escapes to, for example, linking to nodes with "|" in their titles. And it'd be nice if the title-handling code were cleaned up so that ' and " would no longer cause title truncation when replying, < and > would not be stripped (giving titles like "How to use codeuse/code"), etc.

        - tye (but my friends call me "Tye")

[crazyinsomniac]

I vote a big loud NO for two reasons. One, the id://0000 syntaxt don't got anything to do with no kinda RFC or nothing nor does pm strive to conform (we're special). Two, it's been in use for a very very very very long time and a change now, for the benefit of one or two lazy monks will cause more confusion and an adjustment period which would annoy a lot of people (most importantly, me).

 
___crazyinsomniac_______________________________________
Disclaimer: Don't blame. It came from inside the void
perl -e "$q=$_;map({chr unpack qq;H*;,$_}split(q;;,q*H*));print;$q/$q;"

[mischief]

It's not about conforming or not about conforming, it's just an idea to make life simpler. At least, as far as I can tell.

And what about keeping the old format as well? That way noone would get too confused.

[crazyinsomniac]

...just an idea to make life simpler - not really. Life is not any simpler if you save yourself from typing two extra characters. Life is not golf. Furthermore, I doubt it would be much work to implement this, butt time is scarce for the only person capable of doing this, vroom (or some other gods, but they don't meddle anymore), and whilst the update might be simple, appropriate documentation would have to be updtaed and what not. I still don't like it. If you wan't to save yourself from typing an extra few characters, use a cb client and hack the code yourself.

 
___crazyinsomniac_______________________________________
Disclaimer: Don't blame. It came from inside the void
perl -e "$q=$_;map({chr unpack qq;H*;,$_}split(q;;,q*H*));print;$q/$q;"

[r.joseph]

I wholeheartedly agree, and have for some time. Mark down my vote for a definte YES!

r. j o s e p h
"Violence is a last resort of the incompetent" - Salvor Hardin, Foundation by Issac Asimov

[boo_radley]

Chip said :

When you make up your own scheme ("id" in this case), you can do whatever you want after the colon

Well, then :-)