Enhancements for workspace create REST service to support additional parameters

[sbryzak]

It would be useful for the workspace creation REST service to support setting up a new workspace with some additional parameters, such as open files, cursor positions in files, breakpoints, stacktrace info, etc. This would enable a developer to create a new workspace with the required state for working on an issue or feature request with these additional parameter values being provided by the issue tracking system.

This enhancement would require some changes to org.eclipse.che.api.workspace.server.WorkspaceService (che-core-api-workspace), probably in the org.eclipse.che.api.workspace.shared.dto.ProjectConfigDTO class, and changes in WorkspaceManager to support the extra params.

[AndrienkoAleksandr]

@skabashnyuk what do you think about this suggestion?

[gazarenkov]

Workspace API supposed to be client behavior agnostic.

I think we have this things (pretty much the same you requested) when call IDE with Factory parameters. Not sure if it is available on Che assembly as well (not Codenvy only) but still - I believe we should not mix client specific with REST API, let's better keep using factory (on top of ws definition) for that.

[sbryzak]

Hi @gazarenkov , I've looked at the Factory API already (I believe that you're talking about https://codenvy.readme.io/docs/factories ). I don't believe this feature is available in Che, also my concern with using Factory is that it is limited by URL length (see http://stackoverflow.com/questions/417142/what-is-the-maximum-length-of-a-url-in-different-browsers ). The 2000 character limit will easily be exceeded if we are going to be including a list of open files, cursor positions, breakpoints and stacktrace information in the URL. The only reasonable way I can think of to send all this state is in a REST call which would not be restricted by size limits.

[TylerJewell]

Factories have a fixed-length when they are encoded with a hash, such as http://<hostname>:<port>/f?id=<hash-code>. The non-encoded version is one that we have discontinued as it made reading of the URL to complicated. With encoded factories, a factory has to be first created by the user by submitting their parameters over a REST call, those parameters are saved in a database and associated to a Factory, and then the REST service returns the hash code identifier of the Factory.

A user can then invoke a factory with the ID code and the system will then generate a workspace according to the configuration that was previously saved. So, in effect, a Factory implements exactly what you are seeking.

[sbryzak]

@TylerJewell that sounds very interesting, the way you describe it is exactly what I'm looking for. Which REST call is used to create the factory? I see mention of configuring using a JSON snippet passed via URL or the command line here - https://codenvy.readme.io/docs/factories#configure, or is the REST call for creating the factory a different thing? Also, how do we get the factories feature in Che?

[TylerJewell]

If you look at the Swagger within Codenvy, there is a /factory RESTful API that has the various commands around creating, destroying, and invoking a Factory. It's a capability that we have built up over 4 years and goes pretty much to the heart of our thinking. So there is a lot of sophistication around it.

What you see with the factory.json on that link is the data model of the JSON object that has to be passed into the Factory REST method during a creation. That is all of the parameters that we support. Essentially, the Factory data model was designed to take Che's workspace : {} object exactly as it is (without modification) and then an additional set of meta data and policy stuff such as password protection, routing information, where the workspace will reside, and so forth, save it all, and then generate a hash code so that it can be refernced again.

We then have logic to determine what happens if a factory URL is clicked more than once (create new ws each time, reload existing workspace?, singleton ws or single ws / user?). There is a pretty rich sub-system involved with this.

We have been talking with Red Hat management for a number of months about what would be involved with Codenvy open sourcing our Factory capabilities and including them within Che. They are probably better suited to discuss the state of that conversation. They have come to us and asked us to open source some other sub systems within Codenvy as part of Che as well and those discussions are all lumped together.

[sbryzak]

@TylerJewell thanks, I'll checkout the /factory API - offhand do you know if it supports setting the workspace state such as open files, breakpoints, etc as I describe above? I'll talk to my Red Hat team members to find out what's happening with the other stuff.

[TylerJewell]

It does, yes. In the 5.0.0 version that we are shipping with Che, we have been enhancing the "workspace state" object inside of the "workspace" object which factories embody. The workspace state is a server-side set of properties that define (for the client) what it should configure itself to. It has things like open terminals, open files, which folder in the tree should be open, editor layout, client preferences. This state object is far from complete, but it's a server-side object that we incrementally enhance.

If you pass a factory object with workspace state within it, then when the workspace is created the client will be passed this state information and told to configure itself that way.

[TylerJewell]

I think this thread has moved into other directions, so closing it for now.