Re: [orion-dev] Hashbang discussion

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

> Frank Gerhardt <mailinglists@xxxxxxxxxxxxxxxxx>
wrote:
> I dislike this format. I remember reading on
the wiki that Orion wants
> to play nice on the web, including references to REST. I would prefer
a
> true REST format like <path>/<file>?task=xyz&anything=else.

Perhaps you can enlighten me, but I don't understand
why that format is "true REST" and the current Orion format is
not. Keep in mind there are several resources at play here:

1) The application being run
2) The user data that the application is operating
upon.
3) An application operating upon a particular piece
of user data.

In Orion each of these resources have representations
that are addressable/linkable:

1) http://server.com/coding.html
2) http://server.com/file/A/foo.js
3) http://server.com/coding.html#http://server.com/file/A/foo.js

Maybe Tim Bray's problem is with applications that
don't expose 2) at all, which then prevents other people coming along and
doing novel things with the data (like indexing it for search). I agree
that would be bad.

> Having "coding.html" in the URL seems
like an implementation detail
> leaking out.

The editor being used is an important detail that
must be present in the URL. Your proposed task=<someEditor> just
leaks this out in a different way. If you think it important to hide the
detail that we are using HTML, we could equally put that file in a separate
directory and use a URL like http://server.com/coding/#...
This seems like a minor detail at this point.

> What about other representations, in the REST sense? E.g. when I have
an
> file like onlinehelp.html, I would like to be able to use different
> editors for it: task=editSource or task=editWysiwig or task=displayHtml,
> the first or the last maybe being my default.

Sure. Since the particular editor is encoded in our
URL, a method is available for creating URLs for different representations
(different editors operating on the same source code).

> Another aspect is the WebDAV support that I noticed on the roadmap
wiki
> page. For WebDAV you would need to have RESTful URLs anyway. Then
why
> not make them the standard URLs?

A WebDAV URL would give us the URL of the source file,
but not the URL of an editor operating upon that source file. We are avoiding
the common assumption that the server hosting the data has any correlation
to the server hosting the tools operating on that data.

John