[kepler-dev] Kepler user interface + relation to Recito
ian.brown@hsbcib.com
ian.brown at hsbcib.com
Thu Nov 22 00:24:04 PST 2007
I have the same basic reqiurement. Currently, it is implemented with a
couple of custom actors.
First, I have a version of the Monitor actor that instead of displaying
the value, makes it available over JMX. That means it can be monitored in
a web page or using the Sun JConsole app. That works pretty well except
that JMX uses UDP and so the messages are not reliable. For display and
logging that must be reliable, I have a pair of actors based on the
publisher / subscriber model. The difference is that they publish and
subscribe over a TCP/IP socket.
That means, for our models, we actually have 2 models ... one the 'engine'
which has these JMX and Socket publishers. Then, we have a GUI model that
has JMX listeners and Socket subscribers. It works pretty well for us. The
only thing to remember is that you need to add a model time stamp to the
information published and then use something like an XYPlotter on the GUI
side. This is because the model time in the engine is not the same as the
model time in the GUI model.
To see this type of funcionality 'out-of the box' would be great and I
look forward to what Kepler Core can bring us.
Ian
"Edward A. Lee" <eal at eecs.berkeley.edu>
Sent by: kepler-dev-bounces at ecoinformatics.org
21/11/2007 18:57
Mail Size: 14139
To
Matthew Jones <jones at nceas.ucsb.edu>
cc
kepler-dev at ecoinformatics.org
Subject
Re: [kepler-dev] Kepler user interface + relation to Recito
Entity
Investment Banking Europe - IBEU
This idea is quite interesting.
There are a couple of mechanisms in the Ptolemy core that support
something like this. These may be worth looking at just for ideas
(or critique!).
MessageHandler is non-graphical class that handles all error messages
(like exception reports). By default, all such reports go to stdout
and stderr. Vergil overrides this by registering a
GraphicalMessageHandler.
Also, the listener mechanisms (e.g. DebugListener) have this flavor...
Edward
At 03:53 PM 11/19/2007, Matthew Jones wrote:
>Hi Edward,
>
>You're absolutely right about the ptolemy core packages not depending on
the UI. That is an excellent feature, and one which we have used many
times to run ptolemy stand-alone (in CGI scripts, web portal environments,
the nightly build, etc).
>
>It does have its limitations though, such as not being able to use
components that have graphical output when running in batch mode, or not
being able to detach from a running model that one started within vergil,
or not being able to monitor the UI output of workflows that have been
distributed across many different computing nodes. These issues are due
to the dependency of the UI (vergil) on the ptolemy core.
>
>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, altho
ugh 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).
>
>You made some good points about Eclipse.
>
>Hope this clarifies my earlier message.
>
>Matt
>
>Edward A. Lee wrote:
>>A couple of points:
>>- We have always carefully architected the Java classes in the
>> Ptolemy core packages to not depend on the UI, so all of the
>> things you propose for separating execution from the UI should be
doable.
>>- I use Eclipse with Ptolemy II all the time, and find the ability
>> to develop Java classes (actors, etc.) and have them automatically
>> update in the running vergil extremely useful. Setting breakpoints
>> is also extremely useful. But all of these tasks are code development
>> tasks, not model development tasks.
>>- A tighter Eclipse integration supporting model development
>> could be very attractive, but there is a potentially huge job.
>> In particular, Eclipse does not integrate well with the AWT, so
>> all the underlying graphics support in vergil, the plotters,
>> the dialog boxes, etc., would have to be redone. This is a
>> very big job. Is it worth it?
>>- One argument for using Eclipse is to get the one-window style
>> of interface, vs. the multi-window interface currently used in
>> Kepler and Vergil. However, this can be accomplished by a more
>> modest effort. There is a good starting point already available.
>> Invoke vergil -single, and you get a tabbed pane interface where
>> all the models you open end up in the same window.
>>- An Eclipse interface would not make a good interface for the model
>> _user_ (vs. model developer and code developer). Or, more precisely,
>> I would be hard pressed to figure out how to use Eclipse effectively
>> for that purpose.
>>So I would caution against deciding for an Eclipse interface just
>>because Eclipse is cool (which it is). It requires some careful thought
about
>>both cost and benefits.
>>Edward
>>At 10:38 AM 11/19/2007, Matthew Jones wrote:
>>>Hi Tim,
>>>
>>>We have met the Recito developers at last year's miniconference, but we
were not involved in what they did. Our plans under Kepler/CORE for a new
UI are more centered around a clean messaging API separating the user
interface from the execution engine. We are motivated by some use cases
having to do with long-running workflows: the need for workflows to be
able to be executed on various machines, the need to be able to launch the
GUI to start a job, quit the UI but keep the workflows running in the
background (we call it "detached execution") and then reconnect the UI
later to monitor progress, and the desire to support multiple different UI
clients (e.g., Vergil, eclipse-based, and web-based).
>>>
>>>As Kepler/CORE is just starting, we have not yet collected requirements
nor designed the API. This would be done in conjunction with the
community to try to determine what architecture would serve us best. Many
people have spoken of an Eclipse UI, and so I think that would be high on
the list of client environments that we would want to support, although it
would be a lot of work to develop a new UI from scratch, so I'm not sure
whether that would happen in the first pass -- more likely a refactoring
of the current engine/vergil to make it so that they are better separated,
allowing groups like the Recito team the ability to utilize the new
messaging API in their eclipse client.
>>>
>>>Matt
>>>
>>>Tim Van den Bulcke wrote:
>>>>Hi,
>>>>
>>>>I have been following the evolution of Kepler for a while now and I am
very enthousiastic with the projects that are currently being started such
as Kepler/CORE.
>>>>
>>>>I have seen that there exists another project called "Recito" (
http://www.sp-process.it/index.php?option=com_content&task=view&id=23&Itemid=55
) which provides an eclipse-based user interface to Ptolemy and has some
additional actor libraries.
>>>>- What is their relation to the Kepler development team?
>>>>- Are there plans to migrate the Kepler user interface to an
eclipse-based environment (which would be a great enhancement in my
opinion)?
>>>>
>>>>In Kepler/CORE a standalone GUI will be developed, is it the intention
to base this on Recito or will this be done independently?
>>>>
>>>>Thanks a lot for your answers!
>>>>
>>>>Tim.
>>>>
>>>>
>>>>
>>>>--
>>>>_______________________________________________________
>>>>ir. Tim Van den Bulcke
>>>>PhD candidate
>>>>
>>>>ESAT-SCD
>>>>K.U. Leuven
>>>>Kasteelpark Arenberg 10
>>>>B-3001 Leuven (Heverlee)
>>>>Belgium
>>>>
>>>>room: 03.11/14
>>>>tel: +32 16 32.86.43
>>>>fax: +32 16 32.19.70
>>>>email: tim.vandenbulcke at esat.kuleuven.be
>>>>homepage: http://homes.esat.kuleuven.be/~vdbulcke/
>>>>personal homepage: http://timvandenbulcke.objectis.net
>>>>_______________________________________________________
>>>>
>>>>
>>>>------------------------------------------------------------------------
>>>>
>>>>_______________________________________________
>>>>Kepler-dev mailing list
>>>>Kepler-dev at ecoinformatics.org
>>>>http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>>>--
>>>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>Matthew B. Jones
>>>Director of Informatics Research and Development
>>>National Center for Ecological Analysis and Synthesis (NCEAS)
>>>UC Santa Barbara
>>>jones at nceas.ucsb.edu Ph: 1-907-523-1960
>>>http://www.nceas.ucsb.edu/ecoinfo
>>>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>_______________________________________________
>>>Kepler-dev mailing list
>>>Kepler-dev at ecoinformatics.org
>>>http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>>------------ Edward A. Lee
>>Chair of EECS and Robert S. Pepper Distinguished Professor
>>231 Cory Hall, UC Berkeley, Berkeley, CA 94720-1770
>>phone: 510-642-0253, fax: 510-642-2845
>>eal at eecs.Berkeley.EDU,
http://www.eecs.berkeley.edu/Faculty/Homepages/lee.html
>
>--
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>Matthew B. Jones
>Director of Informatics Research and Development
>National Center for Ecological Analysis and Synthesis (NCEAS)
>UC Santa Barbara
>jones at nceas.ucsb.edu Ph: 1-907-523-1960
>http://www.nceas.ucsb.edu/ecoinfo
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
------------
Edward A. Lee
Chair of EECS and Robert S. Pepper Distinguished Professor
231 Cory Hall, UC Berkeley, Berkeley, CA 94720-1770
phone: 510-642-0253, fax: 510-642-2845
eal at eecs.Berkeley.EDU,
http://www.eecs.berkeley.edu/Faculty/Homepages/lee.html
_______________________________________________
Kepler-dev mailing list
Kepler-dev at ecoinformatics.org
http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
************************************************************
HSBC Bank plc may be solicited in the course of its placement efforts for
a new issue, by investment clients of the firm for whom the Bank as a firm
already provides other services. It may equally decide to allocate to its
own proprietary book or with an associate of HSBC Group. This represents a
potential conflict of interest. HSBC Bank plc has internal arrangements
designed to ensure that the firm would give unbiased and full advice to
the corporate finance client about the valuation and pricing of the
offering as well as internal systems, controls and procedures to identify
and manage conflicts of interest.
HSBC Bank plc
Registered Office: 8 Canada Square, London E14 5HQ, United Kingdom
Registered in England - Number 14259
Authorised and regulated by the Financial Services Authority.
************************************************************
-----------------------------------------
SAVE PAPER - THINK BEFORE YOU PRINT!
This transmission has been issued by a member of the HSBC Group
"HSBC" for the information of the addressee only and should not be
reproduced and/or distributed to any other person. Each page
attached hereto must be read in conjunction with any disclaimer
which forms part of it. Unless otherwise stated, this transmission
is neither an offer nor the solicitation of an offer to sell or
purchase any investment. Its contents are based on information
obtained from sources believed to be reliable but HSBC makes no
representation and accepts no responsibility or liability as to its
completeness or accuracy.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/kepler-dev/attachments/20071122/8e326ae0/attachment.htm
More information about the Kepler-dev
mailing list