Hi Ed,

Thanks for sharing those concerns, I'll try to propose some possible
solutions inline.
As a preamble note, this is an idea revived in the context of jdt.ls and
cloud deployment of an IDE to multiple users; I'm not trying to change
anything in regular and legacy single-user desktop IDEs -which do work
great as it and for which multi-worspace wouldn't help at all-.

Sorry, but my knee-jerk reaction is very negative.  Just imaging the number
> of places in my own frameworks that would need to be reworked gives me cold
> shivers.  Imagining trying to maintain compatibility between a
> before-multiple-workspaces Eclipse and an after-multiple-workspaces Eclipse
> makes the cold shivers worse.
As usual, any change should be backward compatible to minimize, and even
annihilate, the need for specific adoption for downstream projects.

> So many questions arise.  For example, instance preferences are stored in
> the <workspace>.metadata folder because of course they're per-workspace
> preferences.  So as a user, when I change a preference, in which workspace
> would be be stored?
The use-case I have in mind for multi-workspace is definitely not the
Eclipse IDE or SDK which is better remaining a single user/workspace app.
It's more for cloud deployments, like jdt.ls in Eclipse Che, where
multi-tenancy can lead huge savings of energy/dollars/hardware... Those
would be for future specific applications that want to allow such
multi-workspace mechanism. I don't expect nor want legacy apps like the IDE
should change behaviour by default.
So everything would remained stored the same way in all existing apps which
would use the "default" workspace of the application, as selected by user.

> Also, often code in any specific framework really has no context, at least
> not currently.  E.g., when EMF saves a resource with the URI
> platform:/resource/<path>/<file>, it uses a utility like the following,
> of course assumes there is but one workspace with one workspace root:
>       IFile file = workspaceRoot.getFile(new Path(platformResourcePath));
> What if there are multiple workspaces and each one has a corresponding
> IFile for that URI?  To me the questions of "how would that work?" seem
> endlessly endless.  :-(
Similar issues should already exist file.getPath() and other existing
methods in current implementation. I have no real knowledge (yet?) how this
can work in a backward compatible way.
I imagine the simpler is that apps that would support multiple workspaces
declare it early before starting any workspace to "enable" the new things,
and maybe change the behavior of some methods when workspaces are qualified
or something like that. For example, the path URI could be turned in the
form of "platform:/resource/workspaceId/path/file" and the various possible
method be able to support such path/URIs when multiple workspaces are on...
Apps that wouldn't declare support for mulitple-workspace should remain on
the exact same behavior.

> It seems to me there are so many other places where effort to improve
> things could/would be better focused.  But in the end, the fundamental
> question, "What does such a new feature buy us that would offset the huge
> disruption?", needs a very good answer.
If we want Eclipse Platform and jdt.ls and many other to remain relevant in
Cloud IDE, we do need it. Without multi-tenancy or other way to save a lot
of resources when multiple users want Java support in their Cloud IDE, then
jdt.ls is very expensive in term of resources for cloud deployment, and
Java will become a very expensive language to have devtools in the cloud.
As a result, many vendors will favor leaner stacks or stacks which have
more scalable language servers, users will go using the recommended stacks
(which wouldn't be Java and Eclipse-based ones), and the investment in
Eclipse Platform and Java will decrease.
It seems to me, based on the current market of DevTools and the strategy of
my employer, that offering multi-tenancy will eventually become a
requirement to keep Eclipse relevant in the cloud IDEs world.

> On that front, it seems to me that a single workspace can already contain
> arbitrarily many projects.
Sure, but they're not isolated between users.
I want projects from user A to not be accessible to user B. Moreover, I
want user A and user B to work on different versions of the same project.

> As such, an operation/action where one could specify "Import Projects from
> Other Workspace" could accomplish much the same goal, wouldn't it?  I.e.,
> it seems to me the goal, which I assume is to have a workspace with more
> projects it in, might be better directed toward a utility for composing
> multiple workspaces into a single workspace.  This could be accomplished
> with no disruption to anyone else because the end result is simply a single
> workspace.

Unless I missed something, this proposal doesn't work for the requirement

> So that's my feedback.  Try to clearly articulate goal.  It seems to me
> that "multiple workspaces" is a way to achieve some goal, but is not really
> the goal in and of itself and may well not be the best way to achieve the
> real underlying goal.
Thanks for the feedback. I hope my answers did clarify the goal here. Feel
free to ask again and again until I didn't manage to make myself clear
about the "why", I really appreciate your feedback.

Mickael Istria
Eclipse IDE <https://www.eclipse.org/downloads/eclipse-packages/>
developer, at Red Hat Developers <https://developers.redhat.com/> community
Elected Committer Representative at the Eclipse Foundation
<https://www.eclipse.org/org/> board of directors
platform-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit

Reply via email to