| [orion-dev] Hashbang discussion |
In the past days, there's been a discussion in the Twitterverse/Blogosphere about the use of hashes in URLs. A good entry point is this blog post by Tim Bray where he recommends that hashes not be used for navigating to different pages of a web site:
http://www.tbray.org/ongoing/When/201x/2011/02/09/Hash-Blecch (beautiful URL by the way! ;-)
I just wanted to make you aware of this discussion and add my two cents with regards to our current use of hashes in Orion URLs.
In Orion, we try to separate functionality between different pages. The rule of thumb is: page == resource + task, i.e. the URL in your address bar should change when you change the resource you are working with, OR when you change the task that you are performing. So when I am editing file1.js, I would see a different URL than when I edit file2.js, and when I am looking a the revision history of file1.js I would see a different URL than when I am editing file1.js.
The question then is, how do you combine the two parts in one URL? Here are a number of options:
- http://server/path/to/file1.js?task=edit
- http://server/edit/path/to/file1.js
- http://server/edit?file=/path/to/file1.js
All of these would be valid choices from my point of view, but the one thing these URLs have in common is that the server needs to know something about them to be able to serve the right content. Our current server is relatively dumb and doesn't have any knowledge about the client-side UI, all it does is serve files and respond to HTTP requests according to our server API. That is the reasoning behind choosing the following format for our URLs:
http://server/coding.html#/path/to/file1.js
This URL has all the disadvantages that Tim Bray is talking about, but it has the nice property that we can just change the file coding.html (or one of the files it references) and reload our web page to make and test a change to our UI. Or if I am editing the Orion code that I am running and have shot myself in the foot, I can undo my change in another browser tab that still has the previous version running, by changing the hash part of the URL to be the file I need to revert.
So it's just a point in time where this URL format seems to be the most convenient for our development. To make it easy to change the format in the future, we should ensure that the bulk of the client-side code we are writing does not make *any* assumptions about the form of the URLs. For example, one easy change would be to do this: http://server/coding.html?file=/path/to/file1.js - the server would ignore the file parameter in the URL, and our client side code would just pick that up similar to how it picks up the part after the hash now. This would only break the esoteric "save yourself after shooting in the foot" case.
So, to sum up, we should probably pick a form of URL that makes sense at some point, but I don't think we have to make a decision right now. Maybe change the URL format every now and then to keep us on our toes? ;-)
Also, remember whenever there's a discussion about the "one true way" to do things, it helps to remember that there is no true way. Almost always, it is a matter of trade-offs.
Boris