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,
_______________________________________________
platform-dev mailing list
platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-dev