[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [orion-dev] Hashbang discussion
|
On 2/11/2011 2:39 PM, Boris Bokowski wrote:
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! ;-)
But Bray's arguments are Web 1.0 arguments. Orion is a Web 2.0 application.
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.
Which is why they don't make sense. These are Web 1.0 server URLs.
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,
Well this URL has the properties that Tim Bray describes, but they are
not disadvantages. His description of the process involving # is exactly
the model behind Orion.
If you really want to have a Web 1.0 story for this URL, coding.html is
a humongous Web page with an editor for every file in your workspace,
given by different values after #. Now those clever folks at Orion
noticed that they did not need to render all of the lines for large
files. In fact they figured out that they don't even need to load all of
the editors at once. Sweet!
jjb
