Re: [orion-dev] Hashbang discussion

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

I'm joining this discussion a bit late,
but just wanted to chime in to say I completely agree with John B here.
Tim Bray's argument seems to boil down to "don't write client-side
browser applications". The client should be dumb and the complexity
should all be on the server. This isn't particularly instructive for those
of us focused on writing client-side browser applications...

John A

"John J. Barton" <johnjbarton@xxxxxxxxxxxxxxx>
Sent by: orion-dev-bounces@xxxxxxxxxxx

02/12/2011 12:11 AM

Please respond to
johnjbarton@xxxxxxxxxxxxxxx; Please respond to
Orion developer discussions <orion-dev@xxxxxxxxxxx>

To	orion-dev@xxxxxxxxxxx
cc
Subject	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
_______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/orion-dev