FTWM 2008-08-25

Agenda

• Review updates to team page.
  
• Review updates to requirements document.
• Review updates to glossary.
  
• Discuss term bundle.
  
• Development status updates.
• Identify milestones and key tasks for road map.
• How to automate assignment of IDs to bundles, etc?
  

Meeting notes

 Participants: Aaron, Tim, Sean, and David

Team page updates

Everyone agreed the reorganization of the team page looks good.

Requirements document

• Tim made the changes we discussed previously and added the new ones he proposed.   He also added a limitations section and a list of assumed functions of other systems.
• Issue: Should the Extension Framework enforce versioning of bundles?  Or should it simply be recommended framework usage?
• Aaron points out that OSGi does not enforce versioning, and he doesn’t know if we can in fact extend OSGi to do so when loading bundles.  Could we have the build system enforce versioning instead?  Tim thinks run-time version validation very useful (at minimum verifying that all bundles contains valid-looking version metadata).
• Tim says he's thought of OSGi as a platform for starting our work from, rather than using it as is. He does not believe our requirements are likely to be met exactly by OSGi (or other framework). and If it's not it easy to adapt OSGi for our purposes then this would be a concern to him.
  
• Issue: Should we start working on the requirements document for the actor repository with the functions of discovering, downloading, and uploading packages?
• Tim points out that we agreed at the developers meeting that a separate working group would deal with the repository for actor/workflow sharing.  He suggests the Framework team assume that this system will be developed in the future.
  
• Issue:  Should all Kepler/CORE developers be routinely testing and running Kepler on Windows, OS X, and Linux platforms?  Or should we split up the platform-specific testing duties across different institutions?
• Aaron points out that if a Core development team is building and running software that is meant to be compatible on multiple OSes it certainly seems like they should at the very least have access to those OSes even if they aren't routinely using them.
  

Glossary discussion

• Tim asks what the distinction between bundles and archives is.  Is every archive a bundle?
• Aaron says bundles should not contain other bundles (if we are using the OSGi terminology here).  However, we can allow archives to contain many bundles.  So bundles and archives are different.
• We agreed that the term bundle should refer to OSGi-compatible bundles only and not used in a broader context.
• The extension terminology is similarly problematic.  Aaron says we should stop referring to the ‘ppod extension’ and say something like ‘ppod module’, ‘ppod feature’, or ‘ppod package’.

Development status updates

• Aaron has moved his work on the OSGi packaging of Kepler to the repository trunk.  There is a new build file that can become the bundle-building system for the future, but Aaron will be adding new targets to the main build file for immediate use. 
• Aaron has had problems separating Kepler and Ptolemy into two different bundles, apparently because Kepler assumes a specific location for the PTII directory.  If this issue can be resolved then we can do the split.
• Aaron will try to have the OSGi version of Kepler building by the end of the week.

Newly proposed milestones

• Milestone:  Upgrade object manager to allow actors not included in the base system to depend on jars not in the base system.
• Milestone:  Allow modules to specify additional configuration independently of the base system.
• Milestone:  Allow modules to provide and access resources independently of those provided by the base system, say within jars.
• Milestone:  Refactor Kepler into multiple modules [need to phrase this in terms of a visible benefit to developers or users].
• Milestone:  Remove any remaining dependency on KEPLER and PTII environment variables [need to phrase in terms of a benefit].
• Milestone:  Enable multiple Kepler configurations in a particular installation, rather than one configuration per .kepler directory.

ID assignment

• We would like a system for assigning IDs to new bundles, actors, etc, automatically.
• One challenge is that when working offline (on a plane, while off the grid, etc) there is no way to get IDs from an online ID provider.  
• Universally unique IDs (UUIDs) are easy to generate offline and without central coordination, but are hard for humans to parse. 
  
• Bertram has suggested that we generate UUIDs when offline and create a human-readable, centrally assigned synonym (e.g. an LSID) when back online.
• The question then arises:  do we continue to respect the UUIDs once the LSID has been assigned, and how much complexity would this introduce?