Community
Participate
Working Groups
This issue is similar to the completed "reimplement Project API from server-side to client-side" ( Bug 415356 ) and is important for the ongoing projects ( Bug 415338 ) and server metadata ( Bug 412995 ) features. Currently when you log into Orion, the client-side performs a GET /workspace to get the workspace metadata including the list of projects, and if a workspace does not exist a POST /workspace is made to create a workspace. We are planning to change this have the workspace metadata available via the File API, stored in a workspace.json, and have the client-side manage the workspace. We need to update the server to make the workspace metadata available and then we can deprecate (and remove) the Workspace API.
The current "workspace metadata" I know about on the server is essentially a list of server paths where the workspace contents are stored. I don't see this as something that can be managed by the client, or that a client would ever care about, and of course is a security risk to expose to clients. There are likely other kinds of metadata (settings, etc) that could be exposed to, and managed by, the client. Maybe we're just talking about different things here.
(In reply to comment #1) > The current "workspace metadata" I know about on the server is essentially a > list of server paths where the workspace contents are stored. The "workspace metadata" is exactly a top level folder on the server with a list of server paths. We currently make use of only one top level folder and give it the id of the user. For the user anthony, we have a workspace at http://localhost:8080/workspace/anthony. We would like use the term workspace to be concept managed by the client through a workspace.json, where the workspace is a list of projects. Projects should also be managed client side. We have a design goal for workspaces and projects to be managed using the File API. I propose that we move the top level folder managed by the workspace API into the user API (or an API not called workspace). When you create a user, you could also get your top level home folder, at http://localhost:8080/file/anthony, without having to create it via a separate POST. I would also like to open up the server to allow folder creation under http://localhost:8080/file/anthony, currently to create folders under the top level folder, you need to use the workspace API. I am not sure how to handle the "Link to Server" support, but it does not seem to fit on the workspace/project API since going forward it is neither a workspace nor project, simply a linked folder on the server. Let me know if this does not make sense.
To confirm again, here is what I am thinking: We want to maintain the ability on the server that allows workspace and project creation via the server Workspace API. We want to allow clients to be able to create, edit and delete workspaces and projects using the File API, workspace.json and project.json. Server side, when you create a user, you also get your top level home folder, at http://localhost:8080/file/workspaceid, without having to create it via a separate POST. The top level folder will be a workspace containing a workspace.json. This will mean that the first GET /workspace will already exist and you will not need to POST to create a workspace. We need to open up the File API one level to allow folder creation under http://localhost:8080/file/workspaceid, currently to create folders under the top level folder, you need to use the workspace API. This allows the client to create the project folder and project.json directly.
(In reply to Anthony Hunter from comment #3) > To confirm again, here is what I am thinking: > > We want to maintain the ability on the server that allows workspace and > project creation via the server Workspace API. > > We want to allow clients to be able to create, edit and delete workspaces > and projects using the File API, workspace.json and project.json. > > Server side, when you create a user, you also get your top level home > folder, at http://localhost:8080/file/workspaceid, without having to create > it via a separate POST. The top level folder will be a workspace containing > a workspace.json. This will mean that the first GET /workspace will already > exist and you will not need to POST to create a workspace. > > We need to open up the File API one level to allow folder creation under > http://localhost:8080/file/workspaceid, currently to create folders under > the top level folder, you need to use the workspace API. This allows the > client to create the project folder and project.json directly. Met with John and Simon and we agreed this is what we want to move to. One tweak is that we need to be careful not to expose server metadata to the client. In 4.0, we will not expose the user root folder, user.json or content location of projects.
(In reply to Anthony Hunter from comment #0) > This issue is similar to the completed "reimplement Project API from > server-side to client-side" ( Bug 415356 ) and is important for the ongoing > projects ( Bug 415338 ) and server metadata ( Bug 412995 ) features. OK, when I was originally planning this out, I had imagined a design where the client and server would share the same meta data. For many reasons, in the short term this is not going to work. I do not think we plan to remove the Workspace API just yet either. I am going to mark this no plan to fix for 4.0 and we can raise a new bug when we get further along in the design. This issue is not blocking the server metadata ( Bug 412995 ) feature either.
We still have the requirement that the projects client needs to do all of its work using the File API and not depend on the Workspace API. This means we want the client to be able to update the workspace.json under the root folder as well as be able to create folders under the root. So I should be able to GET and POST http://localhost:8080:/file/anthony/workspace.json and POST http://localhost:8080:/file/anthony/project
(In reply to Anthony Hunter from comment #6) > We still have the requirement that the projects client needs to do all of > its work using the File API and not depend on the Workspace API. > > This means we want the client to be able to update the workspace.json under > the root folder as well as be able to create folders under the root. > > So I should be able to GET and POST > http://localhost:8080:/file/anthony/workspace.json and POST > http://localhost:8080:/file/anthony/project I have pushed the commit: git.eclipse.org/c/orion/org.eclipse.orion.server.git/commit/?id=416fc0647042129c5b713563139164492ce70f38 Just like Bug 412995 , you need to set: orion.core.metastore=simple orion.file.layout=userTree to use this feature. This change allows you to create folders using /file/{workspaceId} as well as create and edit files at /file/{workspaceId}/{file}. This also works: http://localhost:8080/edit/edit.html#/file/{workspaceId}/workspace.json You definitely cannot add a project to the projectNames in workspace.json without the server metadata having the projects. If you do this, internal services such as the indexer and decorators throw some of exceptions. To fix this issue, when you create a folder (project) using POST /file/{workspaceId} , the server metadata will synchronize on the first internal call to readProject(). It sees the folder and updates the projectNames in the workspace.json. I will write some more JUnit tests tomorrow, but from the client side, you may not need to update the workspace.json after creating the top level folder using the File API.
I am not sure if projects are taking advantage of this feature in 4.0. But the preliminary work is complete.
