Mickael,
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.
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? 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. :-(
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. On that front, it seems to
me that a single workspace can already contain arbitrarily many
projects. 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.
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.
Regards,
Ed
On 04.04.2018 17:51, Mickael Istria wrote:
Hi all,
In the general idea of improving Eclipse Platform (use case here would
be JDT-LS) for the cloud, I'm wondering whether some of you already
considered, tried or evaluated making Eclipse Platform multi-tenant in
term of workspace, basically having the same instance able to work
simultaneously with different workspaces, 1 per user/task/whatever ?
Technically -for the public usage-, it would mostly be about avoiding
references to ResourcePlugin.getWorkspace() in favor of resolving
workspace according to the context (using for instance
file.getProject().getWorkspace() instead of
ResourcePlugin.getWorkspace()) and to introduce a new
ResourcePlugin.getWorkpace(key) method.
But I imagine it's not so simple and there are more things to
consider. Hence if someone already have some feedback on this work,
it'd be greatly appreciated!
Cheers,
--
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
platform-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-dev
_______________________________________________
platform-dev mailing list
platform-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-dev