GUI artefact without Project Manager integration

[lolczak]

General Summary

To integrate with Visual Studio Codespaces we need to have GUI without communication with the project manager. It should take language server addresses as parameters and communicate directly with a running language server.

Motivation

As Visual Studio Codespaces is provisioned per project, the backend service will comprise of a running language server having configured project root.

[farmaazon]

A couple of questions:

• It should take language server addresses as parameters

  You mean here a parameters of our electron app? Or we should provide files to store on a webserver and allow to run IDE in browser, and the adress will be e.g. in GET arguments?

• We will be unable to rename projects without project manager. And also we won't know the project name with current LS API.
• How it is important? Taking it right now will greatly affect our timeline, probably we need to postpone some deadlines for features @sylwiabr

[wdanilo]

@farmaazon its is quite important. It would probably block our cloud development. Could you tell what "greatly affect our timeline" means? What is "greatly"? Without knowing that, no one can provide any answer here.

By the way, I'd be thankful if we always tell about required additional time to implement a task in detail. Telling only that it "greatly" increases a time gives @sylwiabr and me no information and it always just causes a lot of ping-pongs, phone calls and occupies a lot of time to all people involved in the discussion. Sure, we need to chat about this decision, but the first question always is "how it affects the timeline in details".

[farmaazon]

@farmaazon its is quite important. It would probably block our cloud development. Could you tell what "greatly affect our timeline" means? What is "greatly"? Without knowing that, no one can provide any answer here.

By the way, I'd be thankful if we always tell about required additional time to implement a task in detail. Telling only that it "greatly" increases a time gives @sylwiabr and me no information and it always just causes a lot of ping-pongs, phone calls and occupies a lot of time to all people involved in the discussion. Sure, we need to chat about this decision, but the first question always is "how it affects the timeline in details".

And I just asked "How it is important?". The importance of task rarely is affected by the time of implementation. I just need to know it is should be done before other tasks we have on timeline? The Collapsing Nodes? The Searcher? Shall I estmiate it ASAP? Or can I put it into the our process of refinement tasks, so it will be estimated probably on next Refinement and implemented at the next sprint?

As it is "quite important" and not "very urgently important", I assume I can do it in the our process.

Additionally, I cannot reliably estimate task if I won't get the detailed requirements first. @lolczak can you answer my first two questions in the comment above?

[lolczak]

ad. 1) We need a GUI artifact that will be embeddable on a website or inside Visual Studio Code as an extension. So, the solution must enclose both scenarios.

ad.2 We won't be able to rename the project. You can propose API to pass the project name to the GUI.

[farmaazon]

@lolczak Ok, also read https://github.com/enso-org/cloud/pull/14 and as I understand the first step is to make an electron app which allows pass the LS address as an argument, and will read project name from the some new function in LS API and won't allow to change that name. The next steps will turn out during the further investigations. Is that right?

Creating task for Engine for adding endpoint with project name will be also part of this task

[lolczak]

@farmaazon No, we need an embeddable version that we can embed either on a web page or inside Visual Studio Code. Both connection URLs and the project name will be injected somehow. There won't be a new LS API for gathering the project name.

[wdanilo]

@farmaazon @lolczak @iamrecursion - I think you should have a call to discuss it. It seems like a bigger decision here that needs to be done fast.

[notdanilo]

@lolczak I understand that the project manager is necessary part of our custom IDE. It would be interesting to understand how project management with VSCode is envisioned if Engine already have thoughts about it.