You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@zeppelin.apache.org by "Lee moon soo (JIRA)" <ji...@apache.org> on 2016/11/22 18:04:58 UTC

[jira] [Created] (ZEPPELIN-1699) Unify AngularObjectRegistry and ResourcePool with AccessControl

Lee moon soo created ZEPPELIN-1699:
--------------------------------------

             Summary: Unify AngularObjectRegistry and ResourcePool with AccessControl
                 Key: ZEPPELIN-1699
                 URL: https://issues.apache.org/jira/browse/ZEPPELIN-1699
             Project: Zeppelin
          Issue Type: Improvement
            Reporter: Lee moon soo


AngularObjectRegistry provides mechanisms that interpreter and front-end communicate. It's main features are
  
  - Pass object from back-end to front end, vise versa
  - Provide listener for object update
  - Persist into note.json and restore
  - Location where it belongs to (paragraph or note)

ResourcePool provides mechanisms to different interpreter share the object. It's main features are

  - Location where it belongs to (note, paragraph)
  - Search all objects in all interpreter processes
  - Read object from the other process.

I think ResourcePool and AngularObjectRegistry can be merged while they share the same key concept. Share the object between different processes (interpreter<-> interpreter, or interpreter <-> front-end). 

Let's call new unified facility as 'ResourceRegistry', which will provides following features
  - Each object provides where it belongs 
      - which interpreter creates, in which note, in which paragraph
  - Access control of each object. 
      - accessible from other paragraphs
      - accessible from other notes
      - accessible from other users
      - accessible from other interpreters
      - accessible from front-end
  - Persist the object into note.json or not
  - Search objects by name, type, noteId, paragraphId
  - ResourceRegistry creates proxy object when accessing object placed in the other interpreter process, instead of serialize and transfer entire object. And the proxy object take are of remote method invocation.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)