Core Runtime Administration API and UI

reTHINK-project / core-framework

The main goal of WP3 is to provide the reTHINK core framework comprised by the runtime environment where Hyperties are executed and the messaging nodes used to support messages exchange between Hyperties.

Apache License 2.0

1 stars 0 forks source link

Core Runtime Administration API and UI #160

Closed pchainho closed 7 years ago

pchainho commented 8 years ago

Some Runtime Core Components like Id Module and Graph Connector (any other?) will require some UI to set or configure some data including:

set Identity to be used
login to IdP
generate guid
manage Graph Connector in general

It is proposed for each component to have a management API that would be used by different GUI clients according to the runtime type:

browser runtime: HTML / Javascript inside the Core Runtime iFrame that would directly invoke management component APIs
NodeJS runtime: HTTPS server with HTML / Javascript that would directly invoke management component APIs

Ricardo-Chaves commented 8 years ago

The policy engine also require an API to visualize, set or configure policies and user options.

Eventually we can have a runtime module or specific Hyperty to interact with the management API. This Hyperty would then be used by applications, which can provide custom graphical interfaces.

pchainho commented 8 years ago

Shouldn't this admin UI be part of the Core Runtime itself and to be provided by the runtime provider?

antonroman commented 8 years ago

I guess we should provide an API to configure Id Module, Graph Connector and policy engine in ReTHINK.js so that that the developer can decide the way it sets the required params. Does it make sense to you? We would provide also a demo GUI for testing purposes.

pchainho commented 8 years ago

Thanks, @antonroman

If I understood you well, I agree. ie these management APIs would be part of the core runtime. On the other side, the GUI itself could also be part of the core runtime, but depending on the runtime type, they would be served in different ways. See what I've proposed at https://github.com/reTHINK-project/core-framework/issues/160#issue-127496881

antonroman commented 8 years ago

Yes, what you propose in the initial comment https://github.com/reTHINK-project/core-framework/issues/160#issue-127496881 sounds good to me.

Ricardo-Chaves commented 8 years ago

Having the core runtime providing a native GUI is interesting, specially to assure that the functionality can be used. Nevertheless, it should be effortless for some one to provide a different GUI (using the management APIs) and have it able to be used.

pchainho commented 8 years ago

@dvilchez pls check whether this is possible in the Runtime Core iFrame.

dvilchez commented 8 years ago

@pchainho I was thinking about that, and I guess we have a bunch of options to face this problem, but the most straightforward to me, as app developer, would be a public API to get and set the configuration and an option (maybe another library) where I can activate a demo UI while I'm developing or debugging my app.

Answering your question, from my point of view, yes we can.

pchainho commented 8 years ago

For security reasons we have agreed not to give apps access to Core Components settings API.

@dvilchez Your proposal for a debug view is interesting.

pchainho commented 8 years ago

Last monday we have discussed about having runtime gui source code in the Browser Runtime. The idea is to have a small settings icon in, say, upper right corner, that on click, a separated Admin Window/Tab is opened. @antonroman ? @dvilchez ?