web ui: status?

[mhaberler]

is there such a thing as a web UI to browse/edit a store?

[markus2330]

No (there was something in python some time ago), but the new gui is qml, so it should be possible to port it. Any plans on that?

[mhaberler]

Not in scope for us - we would be primarily users as we are looking at filling holes by importing a package which fits; bugfixes are ok but I do not see our resources to fill in basic capabilities in libelektra

[markus2330]

A generic web-ui clearly is within Elektra's scope and could be implemented soon. But projects often want customized pages integrated in their already-existing web UI. What is the situation for your project?

[mhaberler]

What I would expect at this time a basic web service is available either through an internal mini-webserver along the lines of node.js/libwebsockets/mongoose, or some integratable backend script which provides a websockets/JSON API to be used with a basic js client, for example something mundane like jquery.js . Probably a node.js npm is the fastest route to get there.

Functionally I would think the qt-gui is a good start.

That boils down to a (optionally authenticated) URI provided by the library if so configured/started. Any pages customization beyond that is out of scope AFAICT.

[markus2330]

What about the priority of functionality?

A suggestion:

1. basic editing+undo+import/export/search as in qt-gui
2. REST interface (curl)
3. basic authentication (mapping to local users)
4. encryption (hopefully for free anyway)
5. input validation of values
6. mounting+display help/plugin infos as in qt-gui
7. listener notification
8. improved authentication (roles, visibility,...)

Everything but 1. is somewhat optional for some type of users.

[mhaberler]

can I adjust priorities a bit:

1. fix notification, then the rest - polling for updates: I'm sorry, this is 2015 ;)
2. integrate elektra api into node.js as npm
   you can fake the notification while working in parallel, but an notify fd in the node backend is key
3. once that works, drape whatever web-side is deemed appropriate - that is all very nice but the backend integration is the swig python: [] throws exception #1 deliverable of the whole effort

[markus2330]

I was only talking about use-cases of web ui. To clarify, I will split
7. listener notification

to:

a. reactive UI, immediately update keys when they were changed by another process
b. Comet/HTTP Push, immediately inform a REST user on KDB changes

b is somewhat an alternative to ZeroMQ. So I thought it would be less important for you to have it.

[omnidan]

If we use redux and react together (with react-redux) we get features like undo/import/export for free as we can time-travel on the immutable states, for exporting/importing we can simply serialize the state into JSON. In addition to all that, we get real time updates of all UI components for free (thanks to reactivity).

The simplest approach would be sending actions directly to the web ui (maybe via websockets) and then handling them via redux.

EDIT: If actions aren't implemented in elektra yet, sticking to the flux standard should be considered.

[markus2330]

http API discussions happen in #921 and #912

[markus2330]

web-ui is now tracked in https://github.com/ElektraInitiative/libelektra/projects/4