The current conversion functions between string/edn/json are not working correctly on clojurescript. In particular, the keys are not converted into keywords when being converted into edn.

The lifecycle test would fail whenever you login as a user which is not the same as the one hardcoded in example event
NB : the lifecycle test is successful if you login as super user

Refactor the run API so that it runs on ClojureScript. Also rationalize the namespaces to make the code organization of the various APIs consistent.

When rethrowing an exception with data (typically an http response) ensure that both the status and body (if it exists) is included in the rethrown exception's message. This helps with tools that display the message but not the associated data.

Optionally cache user credentials to allow automatic re-authentication.

When using the API via clojurescript in the browser, the authentication cookie cannot be set or retrieved. This is a security feature of browsers and cannot be overridden.

The cookies are handled implicitly by the browser and to keep this platform-independent, this should also be the case for the clojure library (Aleph).

If the cookie handling can be made implicit on all platforms, then there will be the need for a "logout" function and probably also a "identity" resource on the server to echo the user's identity (if he has a valid cookie).

Extend the run support to include the deployment and termination of runs.

Test deployments typically have self-signed certificates. To make testing more convenient, add an option to create client instances that do not check these certificates.

Following @loomis's suggestion

The API should also provide a complete set of methods to control the abort status of a run. I'd suggest:

• (abort id reason) to abort a run (with reason being optional)
• (continue id) instead of (cancel-abort) to clear the abort flag and continue
• (get-abort-reason id) (or message if you prefer) instead of (get-abort). This should return nil if the run is not aborted and the reason (or empty string) if it is.
• (aborted? id) to return true/false on whether the run is aborted.

Remove the old login/logout mechanisms from the server once the UI and other clients are using the new methods.

• create run-impl namespace and move there private functions from run
• update public function names and parameters to stop referring to component as node
• update documentation and the demo following the above changes

From @loomis's comment

In general, I think that we need to understand better whether sync/async functions should be created for all of the actions or if just synchronous functions plus the explicit wait function are enough.

To provide a format that is easier to consume and a cushion against changes in the server format, create functions within the client API that return JSON rather than the underlying XML.

When deciding on the schema for the JSON representation, the CIMI system and machine resources should be taken into account along with feedback from PAChA based on use of the run for calculating application prices.

Update the Clojure(Script) API to use the JSON representations of the run and module resources. To simplify the API, remove the XML processing code. Also for modules, provide more information (name, description, logo, and module type) in the "child" list for projects.

Use case: a client should be able to filter run parameters (standard CIMI request) and add as an option that the server establishes an SSE session.

Requirements come from @loomis comment

Currently, the code reads the API's configuration from a file and puts the information into a global var that is read (directly or indirectly) from every function. There are two problems with this:

• Reading from a file will not be possible when using this API from ClojureScript in a browser.
• This does not play well with concurrency where multiple threads may want to access different servers or different runs.

Although dynamic vars are a bit discouraged at the moment, global library configuration is one place where they still make sense. I would recommend:

• Adding a dynamic variable to the config namespace that provides the map of configuration parameters for the full API. (This should not be in the run/run-impl namespaces as this is global to the full API.)
• The configuration map should include the SlipStream server endpoint, user credentials, and HTTP connection parameters.
• The configuration should not include things like the run id, which are specific to a particular resource.
• The root value for the configuration dynamic variable should only contain parameters that have a reasonable default, like whether the HTTP connections should be insecure (which should be false by default).
• Adding utility functions which allow the root binding or a thread-local binding to be merged with additional parameters.

Many people shun dynamic variable, so you should add an optional final parameter to all calls that takes an options/configuration map that will be merged with the value of the dynamic configuration var.

The documentation for the var should include all of the keys that are used in the configuration and what the appropriate values are.

Clean up the dependencies for the Clojure client in preparation of splitting the API in to a core CIMI component and one for the legacy run.

The generated uberjar and RPM appear not to be used anywhere. Remove those modules from the buld.

Add initial SCRUD actions for CIMI resources to the client API. To handle the search and create actions, the CloudEntryPoint must be retrieved to find the appropriate collection URL. The user should be able to specify either the Pascal or kebab case name for the collection.

Following @loomis's suggestion

For the wait functionality, I'm wondering whether or not anyone will want to wait for anything other than the "ready" state.

• If so, then I think that you should expose the wait-state function (probably as just wait) with a flag indicating which state to wait for.
• If not, then just rename wait-state to wait.

The timeout should be a global option in the configuration that can be overridden through the method call. The private function should be moved to the run-impl namespace in any case.

Following @loomis's suggestion

Putting the run id into the configuration is problematic as many clients will be managing more that one run and probably from multiple threads.

I would suggest adding an explicit run id (probably named "id") to all of the functions. This would then allow a sequence of actions to be performed on a single run through the threading operator (->) and also allow the use of partial to create functions that have the run id specified as a closure.

Update the client to allow the use of the API key and secret for authentication in addition to the existing username and password.

In the latest versions of the test-cljs boot task, changes to support pass options to doo and better exit behavior on errors have been added. Upgrade to this version and remove workarounds in build.boot file.

kvlt supports it from 0.1.3-SNAPSHOT as :kvlt.platform/insecure? true/false

Modify the code to support session resource authn.

That is why need to unwrap it with .getCause. Example:

 (catch java.util.concurrent.ExecutionException e (println (:status (ex-data (.getCause e)))))

This might only be happening under lein repl. Need to check. Submit na issue to kvlt.

Use one of

• Happy, cross-platform HTTP client
• cljs-ajax, cross-platform HTTP client

as proposed in
https://github.com/SixSq/SlipStream/blob/master/roadmap.md#slipstream-client-code-convergence

Suggestion: use x-www-form-urlencoded as content-type in login-async function of sixsq.slipstream.client.api.authn

Remark: the current implementation works when default login url is used.

Currently only the collection name tag (as a string or keyword) can be used with the add operation. This is inconvenient because the user who has navigated to the collection, only has the collection URL. Allow the URL to be used to identify the collection.

In all cases, if a collection cannot be identified, then an exception must be thrown.

Following @loomis's suggestion

This would probably be better to eventually implement with core.async to allow a common implementation with Clojure and to avoid having to get explicit times.

The work is being done in https://github.com/slipstream/SlipStreamClientAPI/tree/portable-code branch.

;; ======================================================================
;; Testing with Phantom:

Installing slipstream-ring-container-3.34-SNAPSHOT.jar...

Testing sixsq.slipstream.client.api.impl.run-test

Testing sixsq.slipstream.client.api.cimi-async-lifecycle-test

Testing sixsq.slipstream.client.api.utils.utils-test

Testing sixsq.slipstream.client.api.utils.http-utils-test

Testing sixsq.slipstream.client.api.cimi.utils-test

Testing sixsq.slipstream.client.api.utils.wait-test

Testing sixsq.slipstream.client.api.utils.common-test

Testing sixsq.slipstream.client.api.utils.error-test

Testing sixsq.slipstream.client.api.utils.json-test

Ran 23 tests containing 118 assertions.
0 failures, 0 errors.
TypeError: undefined is not an object (evaluating 'b.a')

phantomjs://code/phantom6484167367852844384.js:81 in onError
java.lang.Thread.run Thread.java: 748
java.util.concurrent.ThreadPoolExecutor$Worker.run ThreadPoolExecutor.java: 617
java.util.concurrent.ThreadPoolExecutor.runWorker ThreadPoolExecutor.java: 1142
java.util.concurrent.FutureTask.run FutureTask.java: 266
...
clojure.core/binding-conveyor-fn/fn core.clj: 2027
boot.core/boot/fn core.clj: 1029
boot.core/run-tasks core.clj: 1019
crisptrutski.boot-cljs-test/eval1539/fn/fn/fn boot_cljs_test.clj: 187
boot.task.built-in/fn/fn/fn/fn built_in.clj: 738
crisptrutski.boot-cljs-test/eval1575/fn/fn/fn boot_cljs_test.clj: 198
adzerk.boot-test/eval308/fn/fn/fn boot_test.clj: 105
boot.task.built-in/fn/fn/fn/fn built_in.clj: 382
adzerk.boot-test/eval373/fn/fn/fn boot_test.clj: 180
crisptrutski.boot-cljs-test/eval1351/fn/fn/fn boot_cljs_test.clj: 96
adzerk.boot-cljs/eval576/fn/fn/fn boot_cljs.clj: 137
adzerk.boot-cljs/eval633/fn/fn/fn boot_cljs.clj: 217
crisptrutski.boot-cljs-test/eval1423/fn/fn/fn boot_cljs_test.clj: 166
crisptrutski.boot-cljs-test/run-tests! boot_cljs_test.clj: 147
crisptrutski.boot-cljs-test/run-tests!/fn boot_cljs_test.clj: 122
java.lang.RuntimeException: Testing sixsq.slipstream.client.api.impl.run-testTesting sixsq.slipstream.client.api.cimi-async-lifecycle-testTesting sixsq.slipstream.client.api.utils.utils-testTesting sixsq.slipstream.client.api.utils.http-utils-testTesting sixsq.slipstream.client.api.cimi.utils-testTesting sixsq.slipstream.client.api.utils.wait-testTesting sixsq.slipstream.client.api.utils.common-testTesting sixsq.slipstream.client.api.utils.error-testTesting sixsq.slipstream.client.api.utils.json-testRan 23 tests containing 118 assertions.0 failures, 0 errors.TypeError: undefined is not an object (evaluating 'b.a') phantomjs://code/phantom6484167367852844384.js:81 in onError
clojure.lang.ExceptionInfo: Testing sixsq.slipstream.client.api.impl.run-testTesting sixsq.slipstream.client.api.cimi-async-lifecycle-testTesting sixsq.slipstream.client.api.utils.utils-testTesting sixsq.slipstream.client.api.utils.http-utils-testTesting sixsq.slipstream.client.api.cimi.utils-testTesting sixsq.slipstream.client.api.utils.wait-testTesting sixsq.slipstream.client.api.utils.common-testTesting sixsq.slipstream.client.api.utils.error-testTesting sixsq.slipstream.client.api.utils.json-testRan 23 tests containing 118 assertions.0 failures, 0 errors.TypeError: undefined is not an object (evaluating 'b.a') phantomjs://code/phantom6484167367852844384.js:81 in onError
file: "/tmp/boot.user5640306971002492609.clj"
line: 41

Document the configuration for controlling the logging of kvlt.

The most recent version of codox now provides a boot task. Switch to codox to avoid a problem where not all namespaces were documented in codeina and where source links couldn't be generated.

This affects the following files:

• jar/project.clj
• jar/resources/deps.edn
• ./jar/src/cljc/sixsq/slipstream/client/api/impl/cimi.cljc
• jar/src/cljc/sixsq/slipstream/client/api/impl/crud.cljc

To confirm

# cd jar

# boot mvn-test
# ls target/sixsq.slipstream.client.api.*.xml
target/sixsq.slipstream.client.api.app-test.xml
... files are there ...

# boot mvn-build
# ls target/sixsq.slipstream.client.api.*.xml
ls: target/sixsq.slipstream.client.api.*.xml: No such file or directory

Add the basic CRUD actions for the event resource to the API. Use the CloudEntryPoint to obtain the necessary resource URL.

Provide an initial API that allows access to the current module resources.

Within the browser, the API is returning raw JSON (without keywordized keys). This is not the case in clojure. As the lookup of resource URLs relies on keywords, make sure that this is consistent on all platforms.

Currently the insecure? and sse? settings will only work for the authn and cimi protocols. Refactor the code so that these also work with the pricing, module, and runs protocols.

Use the session resources to authenticate with a SlipStream server. This should also provide utility functions to determine if the user is logged in (i.e. sees a session when listing session resources) and to log out. As the URLs will be determined from the cloud-entry-point, the separate configuration URLs should be removed.