Description John Arthorne 2011-01-18 15:56:04 EST

We need to figure out the user view of workspaces.
From previous discussions (edited out the discussion of things we've fixed for m3.)

John said:
A "Project" is the root of some file system tree containing data that the tooling operates upon. It could be a directory on the server alongside the tooling, or it could be content in some remote storage such as a Git repo, s3 bucket, etc.  They map to projects in Desktop Eclipse, except in desktop eclipse we layered on additional concepts such as "the root of version control", "a folder that has builders"a folder with natures", etc. My proposal is that in Eclipse web they are purely file system roots, and nothing more.  I'm happy just using the term "Folder" in the client UI.. the only real distinction is that the user has the option to specify the location of the contents of that folder (similar to a Linked Folder in Eclipse desktop).

A "Workspace" is a collection of projects that the user is working on at any given time. A project can belong to multiple workspaces. This is perhaps closer to the concept of "working set" in desktop Eclipse. It is merely a view onto the project space, and I imagine a user might decide to create and discard workspaces as the situation demands without destroying the projects that it references.

<snip>

Your real "root" question is probably what does the root of the navigation table/tree look like? For M3 since we auto-create a single workspace, I believe it should just show the contents of that workspace.  This decision is made today within fileClient.loadWorkspace. Longer term, another option is that it shows all available workspaces (list returned by "/workspace"). The user could then click a single workspace and get a view rooted on a single workspace (perhaps in a separate tab).

Boris said:
can we make Workspaces optional then (the same way that working sets are optional)?  So as a user, you would have a number of projects or file system roots that you make known to the server, and later on, you could organize them into working sets. For example, you might want to scope a search so that it spans multiple file system roots.

Susan says:
I agree that it would be cool to just have a default workspace and if the user chooses to organize the source trees later, they can.  Only when there was a second workspace would we show something like a "workspace list".

We need to be very clear about how search scope relates to all of this.  Even without workspaces exposed to the user, it can seem confusing.  If I've navigated deep into a source tree/project, what does the search box apply to?  The project?  All projects?   The local folder?  Introducing workspaces is yet another grouping of things.