search

noflo / noflo-runtime-base

Base library for building NoFlo runtimes
11 stars 12 forks source link

Flash runtime support #5

Closed djdeath closed 3 years ago

djdeath commented 10 years ago

It would be nice to have the ability to tell the runtime to "flash" its graphs, so it can restore the last flashed state whenever it is restarted.

bergie commented 10 years ago

@jonnor did some work with this and MicroFlo. I wonder how well that would translate to NoFlo?

In the protocol docs we have the network:persist capability, but not yet a message definition for telling a runtime to persist.

djdeath commented 10 years ago

I could add that command to the protocol. Right now I just save graphs on disconnect ;)

djdeath commented 10 years ago

Right now I have list graphs/networks commands :

https://github.com/djdeath/noflo-runtime-base/commit/24438fe986c5e0272ca8dcf434a71a9614bf0107 https://github.com/djdeath/noflo-runtime-base/commit/45aacfddc96c8ce066150cc358e4e519a3508b30

That gives the ability to the UI to get the state of the runtime, instead of erasing what's already there. Obviously it is a different mode for using the UI : https://github.com/djdeath/noflo-ui/blob/live-edit/live.dist.html (the good thing is that it reuses most of the UI's code, apart from a slight modification to noflo-runtime.html, just changes the graph)

bergie commented 10 years ago

@djdeath I think we want an explicit action to persist, since on some runtimes like MicroFlo this will impose significant overhead.

djdeath commented 10 years ago

Sure, but what do we do about the UI? We kind of need 2 different modes (that's how I see the current mode to keep working, but I might be missing something).

bergie commented 10 years ago

@djdeath my current thinking is to have a Save button in the runtime controls all the time when runtime supports it. Will that fit your usecase?

djdeath commented 10 years ago

Yeah, I meant for the load phase. Right now the UI assumes that when you open a project, you need to upload everything, as if the runtime was blank.

bergie commented 10 years ago

@djdeath ah, yes. Maybe start the runtime-driven mode by clicking a runtime in the main screen? @jonnor your thoughts on this?

This could give a nice workflow when we start autodiscovering local runtimes based on zeroconf or Bluetooth. You walk to c-base, and the Ingress Table runtime appears in your Flowhub app...

jonnor commented 10 years ago

@bergie Agreed that the primary user interaction for opening an existing runtime and its state should be by clicking the runtime. It opens some questions though:

On the protocol level, I think that when runtime gets "runtime:getruntime" message, it should inform UI about its full state. For persisted network/components, this would include sending these over. It might be useful to send/persist a project UUID to runtime side, to be able to look up the appropriate project. Ideally we'd also store project revision.

bergie commented 3 years ago

This is less relevant now that noflo-nodejs has the auto-save mode.