You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@toree.apache.org by "Luciano Resende (JIRA)" <ji...@apache.org> on 2017/02/01 17:58:52 UTC

[jira] [Created] (TOREE-368) Enhance the toree client programmin model

Luciano Resende created TOREE-368:
-------------------------------------

             Summary: Enhance the toree client programmin model
                 Key: TOREE-368
                 URL: https://issues.apache.org/jira/browse/TOREE-368
             Project: TOREE
          Issue Type: Improvement
            Reporter: Luciano Resende


The Toree client seems to be a client utility to enable other applications to interact with Toree/Spark. These applications are not based or aware of the ZeroMQ protocol, but nevertheless, we are imposing them on a very similar programming model while evaluating code using the client.

See an example below, where the application programmer has to handle different options, where more than one option can be called per eval result, and the order cannot be known prior to the execution time :

val exRes: DeferredExecution = client.execute(code)
.onResult(executeResult => {
  ...
}).onError(executeReplyError =>{
  ...
}).onSuccess(executeReplyOk => {
  ...
}).onStream(streamResult => {
  ...
})

I was wondering what are the community thoughts on enhancing the client to abstract its programming model, and having all this abstracted and handled on the client implementation, and the eval would return one promise (e.g. onResult which one option would be status success or error) or at most two promises (e.g. onSuccess and onError). 

This is being discussed in the following thread:
https://www.mail-archive.com/dev@toree.incubator.apache.org/msg00942.html



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)