This would allow us to write the GUI in whatever framework we wanted (browser-based might be good), while retaining flexibility in the choice of machine learning framework. It would require writing a transport layer to forward pipeline data from the runtime to the UI and control information the other way. My sense is that browser-based interfaces are the way to go for cross-platform applications, possibly using something like electron to help bridge to the desktop backend. This could also be an opportunity to switch to a new machine learning framework, although I'm not sure what we'd pick instead of the GRT. We could also potentially keep the GRT but replace openFrameworks with some other approach to i/o streams. For instance, we could try wrapping the GRT as an npm module and then use node for i/o (to both the input and output streams and to the GUI). We'd then might want a GUI for selecting i/o streams, as it would be weird to have part of the example (pipeline definition) in C++ and another part (stream definition) in node / Javascript. Separating the pipeline from the i/o stream specification would further ease the process of porting the pipeline runtime to embedded C++ platforms, too.
This would allow us to write the GUI in whatever framework we wanted (browser-based might be good), while retaining flexibility in the choice of machine learning framework. It would require writing a transport layer to forward pipeline data from the runtime to the UI and control information the other way. My sense is that browser-based interfaces are the way to go for cross-platform applications, possibly using something like electron to help bridge to the desktop backend. This could also be an opportunity to switch to a new machine learning framework, although I'm not sure what we'd pick instead of the GRT. We could also potentially keep the GRT but replace openFrameworks with some other approach to i/o streams. For instance, we could try wrapping the GRT as an npm module and then use node for i/o (to both the input and output streams and to the GUI). We'd then might want a GUI for selecting i/o streams, as it would be weird to have part of the example (pipeline definition) in C++ and another part (stream definition) in node / Javascript. Separating the pipeline from the i/o stream specification would further ease the process of porting the pipeline runtime to embedded C++ platforms, too.