[kepler-dev] Kepler user interface + relation to Recito

[Tristan King]

On Mon, 2007-11-19 at 14:53 -0900, Matthew Jones wrote:

> Thus, the separation that I was referring to is one in which the user 
> interface need not depend on ptolemy core.  We will be discussing how 
> the UI events that are generated by an executing model that would 
> normally be tightly bound to particular actors (e.g., the Display actor, 
> or the XYPlot) would instead be emitted via a messaging API that one or 
> more clients can subscribe to.  Thus, if the Display actor outputs lines 
> of text to be shown to the user, in batch mode, with no client 
> subscribers, those events would simply not be sent anywhere.  However, a 
> textual client could subscribe to those events and write them to a 
> console or log file.  Or a graphical client could subscribe to the 
> events and show the messages in a window.  These client decisions as to 
> what to do with the messages in order to display them to the user would 
> be independent of the ptolemy core.  There wouldn't necessarily even be 
> a need to have the clients be written in the same language as the 
> engine, although for practical reasons it may be more realistic to 
> assume that the client has a java layer to receive the messages (e.g., 
> so that RMI could be leveraged).

This is a big problem i have with running workflows on my web portal.
currently i've built a MoMLFilter that replaces actors such at Display
and XYPlotter with new actors i've built to store the outputs as web
enabled output (i.e. just text for the Display, and as a PNG for
XYPlotter).

This is all well and good. but it requires a lot of extra coding and
work arounds, and it means i need to build replacement actors for each
type of output actor. Having standard, non-gui depended, subscription
based outputs would be a life saver for me.

-Tristan