[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[platform-dev] Multi-workspace Eclipse application
|
Hi all,
Thanks to all for providing the various links and guidance to move ahead on this topic. After your suggestions, I got in touch with John to ask him. He's been so kind to answer and tried to do it publicly but had trouble to join this mailing-list, but sent me answers and allowed for public sharing. So here are the relevant parts of John's answer, quoting him:
""""
In summary, I implemented enough of this to convince myself that it was quite possible to do it. As mentioned on the list there is an old branch with a rough implementation, and more details in this bug report:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=245399
The wall I ran into is that I could make this work for the resource model itself, but the entire eco-system of plugins would not be able to support it without also doing significant work. Therefore it would be impractical to do this for anything except a very small and fixed kernel of plugins. As soon as a plugin was installed that was not multi-workspace aware, it would fall apart.
In the last two years I have been working entirely in high scale multi-tenant server applications, and everything I have learned from that tells me that multi-tenant within a single JVM or even container is not the way to go. Lack of multiple workspaces is not even one of the major problems. The main problems are security and isolation between users, and scalability/resiliency to prevent a single user's state from either leaking or consuming excess resources that impact another user. I think the right architecture here is what I believe Che uses: a single docker container per user, running a single JVM per user, with multi-user achieved by pooling containers on servers behind a common front end.
This is maybe not the answer you were hoping for, but that's my take on it. If you had a scenario with a very small, fixed number of plugins I could imagine multiple workspaces working, but I don't think it would scale, or be secure, or be extensible in any way.
""""
This, added to some other comments some of you made earlier, are for me clear signs that this work is not worth it for the context I had in mind (
jdt.ls in Che).
So I think this fruitful discussion is enough on this topic for my and probably my Red Hat colleagues, and we won't dig any deeper on this nor work on related things until we figure out a new use-case that'd make it interesting again.
Cheers,
--
