Agenda

• Edinburgh summary
• outline for demo data (demo script?)
• plan for 4.1
  • update on XSLT fun (Group A)
  • update on metadata-validator
  • webstart
• permissions
• forums and emails

Notes

• xslt/model

  • Curtis: losing ability to generate old schemas from bioformats?
    • Chris: yes.
    • But generally keeps people moving forward. (cF. C++)
  • Lots of fun for Donald, Chris, Andrew, Jean-Marie
  • Working on tools to work with enums
  • need several more days
  • workflow: working off generated xml with ~all elements (from oxygen)
    • unit testing with python for each transform
  • Curtis: schedule for working version?
    • Mostly waiting on the XSLT. then pretty much done.
    • No lifetime? No. Mostly clean up. Already big changes.
    • But no change in how you think about the data.
  • "setting" v. "ref"? Should now be consistent. 4 setting objects
    • rest are pure refs (i.e. only an id)
  • next thing is then lifetime.

• RoadShow/Edinburgh

  • really successful. users impressed and very much want it. "wow"
  • adminstrator concerned about data duplication
  • should be rolled out to everyone at the same time (all or nothing)
  • mindset: 'it will go into production, i'll spend 4 days, and then it's done'
    • very understandable
  • ImageJ?
    • weren't able to demonstrate it
    • 1 hour demo; couldn't get it in
    • should be in.
  • expanding the road (beyond .dv)
    • heteregenous data
    • imagej: non-deadend, helping me to do my work
    • importing users' data?
    • or gets away from multiple people per machine (watching)
    • ...
    • N things that have to be shown even if user focuses on other pieces

• 4.1

  • webstart?
    • Imperial already doing this
    • cF. Edinburgh "only want to deal with this once"
    • Brian: admin just gets server running then everything else should "just work"
    • Chris: nightmare-ish? then need to keep webstart up-to-date
    • Jason: imperial is trying to minimize the burden of deploying local client changes
    • win v. timeline
  • timeline
    • jason: help us to deliver oct. 1? bug fixing room and some extra demo time for ascb
    • or 4.1 slide to nov/dec? "one more release in 2009"
    • need to decide what, when all the way to Jan. 1, 2010
    • thoughts
      • codegen --> metadatastore, export, ...
      • configuration of importer
      • screening formats
      • QA/Feedback
      • hacked lifetime? convertible?
      • solving data duplication directly after 4.1? preview for ascb?
    • oct 1 (3.5 weeks): not both codegen and export, just import improvements. odd.
    • how much extra time for export?
      • very straight-forward (single-method) with pre-defined metadata (annotations, etc.): 2-3 days
      • blocker is stylesheets & codegen and integration with bioformats & importer. (nebulous beast)
      • stylesheets: finished by next friday then things are on schedule.
    • by end of next week, we estimate codegen and plan Oct 1. as the timeframe. or push N weeks...
  • feedback: who wants more out of it?
    • need to have another meeting. what more can we do?
    • but not spending too much time on it.
  • metadata-validator: reducing feedback that's need. :)
    • structurally validates metadata for each format.
    • metadata-only: no server needed. unit-test driven.
    • as many tests as possible!
    • integrating with QA with trends. "r49285 had 80 errors."
    • then integrating with XML.
  • bioformats on schedule?
    • hcs etc. all fine for oct. 1
  • insight
    • hcs resources
    • viewer level for larger images
    • combining existing drawing with opengl (finding time)
    • trying to avoid rewrite for the moment.
    • but will have to write some thumbnailing code
      • suggestions on opengl? jogl? (too low-level)
      • Jason: can we contact someone
      • Donald: nothing exists
      • VTK? Java-wrapper, etc. (Donald: doesn't integrate with Swing; no GC; otherwise great) * Should we contact them? * The Java bindings seems to be trickling off.
      • VISAD? too high-level (how to optimize?) *
    • timeline?
      • unstable viewer is a serious compromise
      • adjustments on server-side at rendering level to request images of smaller size (cF. split view)
      • gets us half-way
      • adding 2-3 weeks?
  • web
    • integration with carlos went/going well
    • customizing templates for viewer
    • problems with links?
  • Actions
    • @Next week, estimate & write to list.
    • @Estimate another 4 weeks of work for ASCB
      • data dupe, vtk, Michael's matlab ROI/measurement work

• permissions

  • Jason: strong requirement we're seeing from many place. i.e. user requirement, not tech.
  • "switch between private and group"
  • Q: on the fly or server-based?
    • more flexible? per group perhaps.
    • per dataset?
  • josh: per group seems feasible. we can make it configurable and allow chmod
    • but how to deal with mixed containers (some objects from two groups)
    • and if the server guarantees the graphs?
    • Curtis: "private or shared group".
    • Jean-Marie: good compromise
    • you know "groupA and groupB". copy-n-pasting doesn't allow pasting between.
    • PDI structure: be very clear about what's allowed.
    • allowing moving graphs to another groups for user.
    • provisos:
      • you can only be in one group?
      • accessing only one group at a time?
      • all data gets written to a single group? (write only)
      • no mixed owner graphs? (because it breaks moving to another group)
  • pdi
    • Jason: declaring group of project? Chris but what about tags.
  • only private or public. decide on group creation.
    • allowing "publishing" (moving to public group)
    • only seeing one group at a time?
    • asking community? how many production servers where users are in multiple groups?
    • fast user switching...default group as private group plus one more lab, then allow move image to lab
    • "user" group is understandable as "private space"
      • "group space" is also understandable.
      • also solves ldap
      • can't see data from more than one group at a time.
      • all method calls only return from current group
      • adding new rules on top so that users can't get themselves in nasty situations