Community
Participate
Working Groups
Currently our file URLs look like: http://example.com/file/<projectId>/some/path/to/file.txt An alternative would be to use a globally unique user id in the URL: http://example.com/file/<userId>/some/path/to/file.txt Some advantages: - URLs are easier for users to understand - URLs are stable across project delete/recreate Some disadvantages: - Each user can only have one folder with a given name at the top level - Changing ownership of a folder would change its URL - Difficult to have common folders shared among many users - Would need to invent a simple user id when using OpenID
*** Bug 375254 has been marked as a duplicate of this bug. ***
John Barton's proposal from bug 375254: -- Strawman Model: All the current URLs shift under /.orion, eg http://localhost:8080/.orion/navigate/table.html# git projects are cloned under their human name, eg http://localhost:8080/edit/edit.html#/file/G/atopwi.html becomes http://localhost:8080/.orion/edit/edit.html#/atopwi/atopwi.html -- The immediate problem I see with the above is that only one user per server would be allowed to create a project called "atopwi".
(In reply to comment #0) > Some disadvantages: > > - Each user can only have one folder with a given name at the top level > - Changing ownership of a folder would change its URL I count both above in the "advantage" set. > - Difficult to have common folders shared among many users Surely sharing folders under a randomly generated id would not be a good thing. Perhaps github's approach can give some ideas?
The theory was more along the line of google docs where the document URL is not important and ownership is orthogonal to resource location. I thought a web-based IDE would be much more heavily into collaborate tools rather than everyone always having a private copy. I agree the GitHub structure is simpler and I suspect that's where we will end up.
I have started working on this in a branch: http://git.eclipse.org/c/orion/org.eclipse.orion.server.git/commit/?h=johna/bug343264&id=c0c87ed99b28f1dbb4f3aa9a904b8800a59facb7 Currently the basic file operations are working in my branch. I haven't tried Git or site launching yet. There are some broken assumptions in the client that I haven't fixed - in particular breadcrumbs are not showing properly. The current structure I am working with looks like this: /file/<workspaceId>/<projectName>/some/path/to/file.txt Where <projectName> is the user specified name like "atopwi", "orion client", etc. If your workspaceId was equal to the user name, it would concretely look like: /file/johnjbarton/atopwi/orionPlugin.html I am using workspace id rather than straight user id because it seems far too limiting to say each user can only ever have one clone of a project. This is where Orion is quite different from GitHub. I don't do my work *at* GitHub. I clone the Git repository to my local desktop and that is where the work happens. A user might have multiple clones of a given project that they are using in different contexts.
Notes for myself: - Removed abstraction between workspace and file services. The file service is now aware of the workspace service and uses it to look up project content location. Removed concept of alias registry as part of that. - Fixed some code in hosted site servlet that was clearly copied from file servlet, but haven't tested it - Removed support for workspaces that have content from multiple servers. It's not clear this would have ever worked properly given client-side single origin limitations. This was never used or tested. There might be more vestiges of this support still lying around.
The branch was merged into master and has been running for a couple of weeks now.
