2009-05-08 Meeting Notes Schildhauer

5 minute reports from developers on Kepler Core activities

Ben:  working on views (missed some of what Ben said)

Sean: system for adding arbitrary tags to REAP workflow provenance records.  Working to generalize to make
easy to add tags to anything.  Also make it easy to add to library

Christopher: merging DXP and that works. Also tryingo to keep Ptolemy and Kepler trees distinct

David: working on build and module manager.  Have wrapped that up, can now specify whether is beta,
release, etc.  Module mgr to allow scientists to share modules; must work out dependencies among modules
-- still details to address.  For Build System, are still some details to address but not good for
this brief discussion

Dan:  Working on Provenance system.  Recently make sure enuf info for Reporting work and queries
on provenance.

Aaron: working on update to LSID system.  Issue with addressing conflicts based on whether accessing
internet or not to get global ID

JianWu: working on master/slave, globus actor, other distributed execution issues

Chad (Matt reporting)-- working on installer for various platform.  Then will work with configuration system.
Another major task is to coordinate documentation effort for 2.0 release

Kepler/CORE deliverables overview and discussion

Matt spkr: everyone knows history of Kepler core?  (No one speaks up).  So, identified 46 item list of
development tasks.  These all fit into one of 15 "Development Priorities" (see table).  Today we talk
thru items on list to identify:

Requirements
deliverables
milestones
whether is Kepler core task or for allied project

****
Top priorities
****
A. Packaging of modules and actors is top priority.  Matt talks thru slide about this.
Versionining: The LSID system exists, but needs some work.
Depende mgmnt:
Repository: have one, needs work
Licensing: want some decentralized for each module--need lic. mgmnt for module system.


Tim: is easy to develop more bullets, But these need to add up to a coherent product.  Must coordinate
for global function of product
Christopher: often good to identify some "target scientist" for whom we are trying to succeed. 
Maybe this is someone like NEON
Bertram: we have lots of different projects
Matt: Kepler Core must also be sure to make accessible to projects.
Christopher: customers vs stakeholders.  Customer just wants to get job done, isn't vested in our success. 
We should be sure to think about customer, not just stakeholders.
Tim: would be meas of success to see other groups adding modules.

B. Config systems second priority
Shawn thinks we need to drill down on what types of config we talk about. 
Matt: is app config-- which options are needed to run a workflow, as opposed to more system level. 
Talking about configuration.xml as well as UI stuff.
Chad: jedit has good model for how to do.

C. Data access and binding
How to consolidate how Kepler enables scientists to access all diff types of data

****
Middle priorities (Other issues)
****
* document architecture
Shawn: big part of grant was to document architecture, and clarify structure for Kepler
* refactor into core & modules
* distrib exe. env
--- Tim: for parameter sweep, would be nice to have someone "vouch for success.
Christopher: if have 8 cores, just to see that all 8 corese are occupied.

*****
Lower priorities
*****
Need culture of testing

****
Long term Leadership Team (LT) issues)
---------------------------------------------------

Must decide what is core, what not.  E.g. "R module"-- probably not core even tho' is v. important to
several commu. But is probably not fundamental to Kepler.
Ben: will there be multiple varieties of Kepler, or is this at module mgr stage?
Tim: need clarify terminology-- we use "core" many diff ways.
CB: Ptolemy has various configs:  DSP, tiny, whole.  IF "R" ships wiht Kepler, does that mean "R" is
part of Kepler core?  Probably not...

Break

Configuration

Chad: Thinks should be 3 ways to access config:  GUI, programmatic, text files.
Are currently 4 mjr config sys. Ptolemy-- is about half.  Is .properties with UI stuff, SVG, menus-- all in
std java
.properties files. Is legacy config.xml leftover from older Morpho use-- is just for EML specific-stuff?
Maybe a
few other random places. 4th is ad hoc-- uses text file.  Ptolemy also has a user pref. systm.  Also (Dan)
mentions
ontology config files.

Chad recs we consolidate on either one or two of these: suggest the Ptolemy, and the java .properties files.
(Matt taking notes as Chad leads discussion.  Is good page on
#
that we are working thru)

For #7, Matt thinks KC must address the internationalization.

Chad adds that there should be end-user access to config thru GUI!
David says might need to hide some things from end-user

Christopher says shld have capability, e.g., when using "R", can open widget that enables tping in "R commands
and executing.