Upon careful consideration, I decided to keep this posting as a draft and not publish it quite yet. The ideas described within is still in its very formative stages and I don't want to disrupt that by attracting any negative attention. I've kept the post as documentation of the timeframe in which I conceived of these idea, and when I feel it is safe to make an anouncement about it I will release this entry.
As is apt to happen when I am spending some quality time ruling my fiefdom from my porcillain throne, I had an idea last night that was so good that I simply can't blog about it. You see, I think this is a patentable idea - or at least good enough to sit on it until I can figure out if it may be worth real money, so I have to take certain steps to document and protect it before just telling the whole world. However, I can post a blog article about it as long as I keep the specifics out of it, so that I have a record of when the idea occured to me. I'm keeping the rest of the documentation in my Wiki and I'll publish it here after my application is safely on its way to the US Patent Office. ;-)
Many years ago, I remember hearing the term URN (or URI, or some other acronym, it was a while ago). It was supposed to be the internet standard for a URL that never changes - a tag for a specific article or document that could follow it around essentially forever, ending the dreaded 404 not found errors once and for all. Well, whatever it was called, it never materialized and bad links are with us to this very day.
Many companies have made web server products that, assuming you own your domain and continue to use their product, will produce immutable URLs for documents that will not change as long as you keep the document within their system. These products typically use GUIDs in the URL to steer the web application at the desired document. I know IBM makes one, and in 2001 Microsoft bought one called NCompass Resolution that I liked a lot and worked pretty well, then gave it the plain white paper label of CMS for Content Management Server.
CMS2001 and its successor CMS2002 both had this feature of using GUIDs in the URLs to track web pages and other documents posted to web sites. The documents themselves lived in the database, and as long as you didn't do something goofy to them, such as copy them to your desktop, delete them from the server, then copy them back, your URLs would continue to work. I made very good use of the CMS product in promoting the philosophy of web site fitness - keeping a web site healthy though performing small scale regular maintenance tasks at a single page level. Having URLs that let me move documents around when I needed to (for security reasons, organization, whatever) helped a lot.
Recently, I've seen the concept of persistent links come back into fashion. You see this a lot on blogs. However, even in these cases they aren't truly permanent. If the blogger moves his blog to another domain or changes the software he/she is using to run the blog, the link probably won't work anymore. I don't think I can solve the problem of maintaining a link across different domains or software, but there's still a lot of room for improvement here even with individual products and web sites.
Enter SharePoint, another product I truly love. I've been working with SharePoint since 2001, but 2003 was really when I started being able to get work developing with it. This product took off like a rocket, but CMS not-so-much-so. Four years later, SharePoint eats CMS along with its sticker price. At least WSS is still free. :-)
What SharePoint did not eat was the ability that CMS had to create URLs that would not shift. At least, I haven't found this yet in WSS 3.0 or MOSS 2007. Maybe it is in there somewhere, but for the most part, URLs for documents and web pages in SharePoint look more like they did in SPS 2003 and less like they did in CMS.
So here it is in a nutshell. I've developed a process that will address this issue. Actually, I've already come up with two approaches that will both solve this problem, without undermining any of the features that Microsoft has done so well with when making SharePoint the success it is today. I believe these two approaches are possibly the only inexpensive ways to correct this limitation, and I hope to prove it out and (luck and lawyers permitting) maybe I can sell this to somebody (cough, Microsoft?) at a reasonable price. I think it would make an excellent addition to the next version of the software, or a great add on that would make MOSS 2007 even more popular than it is today.