search

noflo / noflo-ui

NoFlo Development Environment
https://app.flowhub.io
MIT License
768 stars 173 forks source link

Respect runtime errors when attempting changes #476

Closed schmurfy closed 2 years ago

schmurfy commented 9 years ago

I am working on a runtime for an home automation project and the way I did it I have specific nodes which I call hardware nodes representing the sensors/ actuators themselves created when the server registers one of them and I am looking for a way way to prevent user removing them and creating them.

is there a way currently to do that ? I did a search but only found an issue on access level which is not really what I need, I only need to "lock" a couple of nodes while allowing anything on all the others.

Edit: I realize that is a special case and might not be something needed for noflo but noflo-ui is a great project by itself and allowing it to be used for more would be really great :)

bergie commented 9 years ago

Right now you can only set all components as read-only, or none (via the component:setsource capability).

However, we're planning to make Flowhub aware of networks that span multiple different runtimes (as https://github.com/c-base/ingress-table for example does, combining a NoFlo main graph, and remote subgraphs running on microcontrollers). With that, you could designate only certain components as coming from a different runtime and hence read-only. #392

bergie commented 9 years ago

Ah, reading this again, it sounds like you mean nodes injected by the runtime and not removable by user. That is closer to how https://github.com/the-grid/msgflo operates, so @jonnor might have some useful ideas there.

Runtimes already send us addnode and removenode events, so we could just listen for them and update graph accordingly. Readonly might be possible by a flag in node metadata.

schmurfy commented 9 years ago

Thanks, I will have a look.

bergie commented 9 years ago

Anyway, this will need some tweaking in Flowhub. But certainly doable.

schmurfy commented 9 years ago

I guess it depends which use case the project wants to support but in my case it would be handy. There is also one thing which surprised me: the noflo-ui gives orders to the backend instead of asking, what I means is that once a command is sent it takes for granted that:

I think building that way reduce the use noflo-ui can have for other use case which were not envisioned, I can think of cases where some connections would just not be possible and the ui would not necessarly have the data or the scope to know it (with a multi user backend for example).

When I first saw the project I thought the protocol would look more like this (to create a node): UI: create node XXX with properties {...} (at this point the ui does nothing visually except maybe showing a loading cursor) Server: node created (now the ui create the node as specified)

This also apply to attributes, I haven't seen a way to specify boundaries, let's say I input 4000 but the value cannot go above 255.

While I am not entirely convinced on the flow based programming topic, at least as a general way to create application, I waited for a long time for a node ui as nice as noflo-ui and allowing it to be used for different needs could help it grows independently of noflo (and having an API is clearly a great step towards that).

That's quite a wall of text for an issue but I am curious to know if noflo-ui is purely seen as the front window for noflo or if it was ever planned to be useable for other purpose.

PS: Until I started playing with noflo-ui the grand goal I was looking after is the node editor from blender (http://4.bp.blogspot.com/-3LJ5AjNrhYs/T60xGVySfEI/AAAAAAAAABE/nk4y2i_03G0/s1600/1node.png) which is a nice example in my opinion of a really nice node based language (in its case this is used for textures and post processing amongst other things).

jonnor commented 9 years ago

Flowhub/noflo-ui is already used for 5-6 different FBP/dataflowish runtimes, some with semantics quite a bit different. However, it is a general IDE for such runtimes. If you want a node editor for something which does not fit the FBPish runtime model, you can use the underlying library http://github.com/the-grid/the-graph

It is a bug that the UI does not handle failing commands. As for edges which cannot be connected, if you annotate different types on such ports there is a indicator of that (pretty subtle right now) Boundaries and other such rich type information we'd like to do with extended annotations on the component messages. https://github.com/jonnor/imgflo/issues/20 On May 11, 2015 11:24, "Julien Ammous" notifications@github.com wrote:

I guess it depends which use case the project wants to support but in my case it would be handy. There is also one thing which surprised me: the noflo-ui gives orders to the backend instead of asking, what I means is that once a command is sent it takes for granted that:

  • it is possible
  • it will succeed

I think building that way reduce the use noflo-ui can have for other use case which were not envisioned, I can think of cases where some connections would just not be possible and the ui would not necessarly have the data or the scope to know it (with a multi user backend for example).

When I first saw the project I thought the protocol would look more like this (to create a node): UI: create node XXX with properties {...} (at this point the ui does nothing visually except maybe showing a loading cursor) Server: node created (now the ui create the node as specified)

This also apply to attributes, I haven't seen a way to specify boundaries, let's say I input 4000 but the value cannot go above 255.

While I am not entirely convinced on the flow based programming topic, at least as a general way to create application, I waited for a long time for a node ui as nice as noflo-ui and allowing it to be used for different needs could help it grows independently of noflo (and having an API is clearly a great step towards that).

That's quite a wall of text for an issue but I am curious to know if noflo-ui is purely seen as the front window for noflo or if it was ever planned to be useable for other purpose.

PS: Until I started playing with noflo-ui the grand goal I was looking after is the node editor from blender ( http://4.bp.blogspot.com/-3LJ5AjNrhYs/T60xGVySfEI/AAAAAAAAABE/nk4y2i_03G0/s1600/1node.png) which is a nice example in my opinion of a really nice node based language (in its case this is used for textures and post processing amongst other things).

— Reply to this email directly or view it on GitHub https://github.com/noflo/noflo-ui/issues/476#issuecomment-100831074.

schmurfy commented 9 years ago

I saw the-graph and I really like the fact that the reusable pieces are already separated projects but noflo-ui mostly works for me as it is.

When I mentioned edge that cannot be connected I was not thinking about types, here are some ideas that come to mind (some could be checked by the UI):

These may not be the best examples but I just feel that some cases would require server validation, I have no real use case for now, I was just throwing the idea :)

The inability to handle failure looks more like a design choice currently than a bug, does that mean the protocol might evolve to handle it ?

bergie commented 9 years ago

I think it as good idea to allow runtimes to "reject" graph changes. Implementation needs some thought, however. And it would be good to have a way to communicate the restrictions in advance so the UI wouldn't tease users with things they ultimately can't do

schmurfy commented 9 years ago

Yes that's the idea and readonly components is only one of the application but the problem is much larger, I already had to work a few times with a ui I had to fight and it just lead to stupid things. When the ui and server have to fight the winner has to be the server and it will frustrate everyone involved from users to developers.

One example I have is a carddav client (for managing contacts) connected to a central custom server where you cannot create or edit everything, in the case the client sends a write request on a readonly contact (at least for him but the client has no way to know in the protocol) and the only way we could deal with that is send back another update request to the client to restore the original data... PS: In my use case the user's changes were still kept somewhere, but that's not relevant here.

As a side note while working with contacts I could also appreciate how the android outlook client works:

schmurfy commented 6 years ago

Has anything moved on this topic ?

jonnor commented 6 years ago

Some related progress:

  1. We have been using the https://msgflo.org runtime for IoT systems quite a bit over the last year or so. Using MQTT for communication. May be relevant to look at for a home automation usecase.
  2. In live mode, Flowhub now respects changes coming from the runtime side. Allows to see new hardware devices popping up.
  3. The FBP protocol is a good bit more documented/specified now, including expected responses for commands. https://flowbased.github.io/fbp-protocol/

And have discovered some more needs like the ones mentioned already:

  1. Msgflo problems with the UI seemingly performing actions that cannot be realized:
    • Removing a node which is a physical hardware device (cannot be shutdown by runtime)
    • Removing an edge which is due to hard-coded MQTT topic names (cannot be re-routed)
  2. In MicroFlo we have another case, which is that only one connection per outport is supported. Should either error or delete old connection.

What would be needed

a) specify a way to identify which request a response is for in the FBP protocol. Sequence number or whatnot. b) Decide whether Flowhub should wait for ACK before considering a state change to be good, or be roll back the change in case of error from runtime. I'm leaning towards the latter, since errors should be relatively rare - and it allows compatibility with existing runtime which don't send ACKs. c) Implement this for all graph-related actions. Might be possible to do generically, since graph has undo capabilities via journal.

schmurfy commented 6 years ago

Thanks for the detailled answer :) One option to really solve the issue would be to have the ui just send request and never suppose anything was done, the runtime can then send the update/create/whatever and update the graph, I doubt the lag it creates would be an issue for any modern system/connection and it would solve all problems mentionned here. It would be a breaking change for existing runtime though.

PS: Looking back at the history of this thread I realize that is exactly what I proposed two year ago xD