I think that this statement makes sense, in the context of the notebook javascript that handles output from the engine.
So, what if we just do the work and add the general capability to have multi-part output (which plot collections/multi-part plots will be a specific case of)?
I have to agree that the ability to return any HTML from your engine function and slap it in the DOM is attractive sounding... and me imposing the rule of never allowing html produced in the engine to be rendered in the Notebook sounds a bit extreme. I think there might be a middle ground, though.
The middle ground has to do with centralizing what has become our convention/standard for
Cell structure and Cell type classification (image cell, text cell, etc.) in the notebook.
The html for the cells are generated by javascript functions, and there are different functions for the different cell types. What if we made it so all output had a 'type', and the javascript always decides how to display the output based on this type attribute.
We could start by making errors (stuff that comes out of stderr) be it's own type of output cell in the notebook.
To throw crazy ideas out, there could even be more explicit ways for the engine to trigger a Cell, or something, to be added by the javascript to the notebook.
Ideas have been brewing on the Wave you(James) were invited to.
We should figure out how we can publish Waves so that everyone on the list can view, and possibly contribute if they have ideas. Good momentum has been building on Matthew's "codenode-transport" concept AND implementation.
I kind of hijacked this thread about the R engine, which is an awesome achievement :)
This is a hot discussion item, though, and I think this is the time to discuss it. Now that we have a few engine types, including one of another language, we have a good set of reference implementations to test what might eventually be called: the X protocol (where X might be codenode, or engine, or notebook, or something).
Also, we should start a project for collecting engine plugins, that may be just a dir
in the root of the codenode repo for now. This could be a 'cookbook'
for engine plugins supported by codenode, but are not part of the
codenode library code (as they are plugins ;).
-Dorian