Personal tools
  • We're Hiring!

You are here: Home Community Minutes Meetings May 2006 Dundee Team Meeting

May 2006 Dundee Team Meeting

...or, the Dundee crowd finally gets to meet itself.

Tentative Schedule


  • get M1 tagged so we can party. (Otherwise, we lose brownie points and dinner time.)


  • 3:30-4: Arrival, hellos, hugs and kisses.
  • ~4 - 6PM.:
    • Fleshing out schedule plus any small testing, fixing we need to do.
    • Also any major admin that needs to be done.
    • Bugzilla config, perhaps?
  • ~8pm dinner.


  • AM: Broad brush stuff. Who is doing what; what are the major roadmap issues.
  • 11:00 Jason leaves.
  • 10am - 12pm: meeting with Catriona. Useable Image project.
  • PM Getting into the gory bits-- the low hanging fruit that we can get done quickly (2.5 release, versioning etc)
    • Version numbering (alpha/m1/etc.) and build/release process
    • "re-productization" of NIO
    • Deploying shoola 2.5
    • Client Java5 versus Java 1.4
      • If so, IQuery/IUpdate can be made generic as well as model.
    • "Resurrecting" from XML.
    • ProjectManagement - rally, GanttProject, fluxx story from Stefan
    • ContinuousIntegration — where to store the builds and the distributions/javadocs/etc.
    • Thumbs up/down stuff
      • getById throws exception on not found.
      • event categories??

Fri: Longer term stuff

  • EmfAsDsl
  • interop
  • Image & Pixels
  • LSID
  • Search — graded queries (UserContext)
  • XML Spec — ST clean up, etc.
  • ImportDiscussion
  • RenderingDiscussion
  • Rois and annotations/classifications
  • <experiment/>
  • Shoomero 1
    • Read/Write (probably few milestones)
    • retrieve rendered image and thumbnail using OMERO.
    • ClientSession
  • Planning the SecurityDiscussion (and initial ideas) (as discussed in March)
    • Public scenario.
    • Read-Write-Analyze (special case of Write) (Result: yes; ILink: ?...; Classify: ??....)
    • Acls, Passwords, login (with groups and events)
  • Major goal is that everyone goes home with very clear map for next 2-3 months. (see below) Could we have this stuff cataloged in Bugzilla and/or itemized in the ProjectManagement software of choice before Stefan/Josh jet away to gay ole Germany?

Short notes

  • Day 1:
    • Arrival... Don't eat sushi at the airport.
    • Milestone 1 tagged : [old-link href="]

  • Day 2:
    • Jason ran through his list and then ran off.
    • Josh and Stefan got indoctrinated by Catriona
    • Version numbering : if need be (future) will put a clear (alpha/beta) in the release name; until then, clear identifier on Tiki, Trac, and in the README about the status of the code.
    • build/release process : continuous integration is coming on line. When it's there, it'll almost be guaranteed that the build won't fail because there'll be lots of annoying emails.
    • "re-productization" of NIO : nio -> romio
    • Client Java5 versus Java 1.4 : must wait until the end of the year (specifically, waiting on macosx 10.3-5 fallout).
    • Deploying shoola 2.5 : no discussion necessary.
    • "Resurrecting" from XML : no discussion necessary.
    • getById throws exception on not found : yes. will be implemented.
    • event categories : overlooked (anyone?)
    • ProjectManagement : we spend a good deal of time talking about this. hopefully we've found the right mix of easy to do and useful. but we'll have to wait and see. is the software we are currently testing.

  • Day 3:
    • EmfAsDsl: waiting on the Java5 decision so we don't have to implement it twice.
    • LSID : plan is to introduce UUIDs on all rows to solve various requirements. also an LSID_id column for linking to imported LSIDs.
    • Search — Stefan is working on a preliminary search api using lucene/compass. This will have to be careful of security issues.
    • XML Spec — Jean-Marie is working on the various refinements of the XML spec.
    • ImportDiscussion & RenderingDiscussion — Chris and Brian will take a look at these pages and respond if necessary.
    • Rois — we spent a goodly amount of time talking about our implementation which is cleanly representable as the many-to-many model, so we retracted all other proposals.
    • Annotations/classifications — the annotation discussion touched on lots of interesting things. We'll need to get a proposal up sometime soon.
    • <experiment/> or "electronic labbook" — we discussed possible implementations from RDF to catalyzer to EMF to xml/xslt. The later seems to be the current favorite.
    • Shoomero 1 — the plan for "Shoomero" is somewhat solid. It needs to be coordinated with the server work. This is the point of trac.
      • Read/Write (probably few milestones) — did we get these ticketed?
    • ClientSession — we didn't discuss this. should we?
    • SecurityDiscussion (as discussed in March) — the discussion got quite specific in terms of both service-method level and data level security. Quite a few good concepts came out of the discussion. The public scenario seems to be no problem. For now, we're going to stick with non-ACL, more-unix-like permissions, but the implementation is open to be changed.
      • Read-Write-Analyze (special case of Write) (Result: yes; ILink: ?...; Classify: ??....)

Action points

Things to do

  • Get annotation proposal written up

Topics that seem to be revisited

  • client session
  • event categories
  • read-write-analyze for security permissions

Topics for later

  • Interop (M4)
  • Image & Pixels; XML re-working (M5)

2-3 month ("5 year"?) plan

Long notes

Lots of implementation details here. Much of this will be added to trac as we go.




Acquisition to RDF w/ Hib. loader (XML Viper, use Oracle or OSS Jean)
Need Bericht for Rally on current state
ArgoUml->XMI->EMF->Hibernate w/ annotations

EventContext with SysProp for inheritable or use SingleThread
Order of SysProp for multiple Omero3 — new login method w/o SysProp
LSIDs on resurrect just like import.
Small tool to do SHA1DB->filesystem for compatibility with OME


Rois, Annotations (<Experimenter/>),
Not happy with new rois
using masks (MaskDefs) with RDF data. need ontology.
predefined forms for quick start
hierarchical? so that predefs can be lumped together?
drop downs for filling forms
search with [a,b) etc. in fields
save; save as ; template ; search?

      <field id='foo' row_start=';' row_stop=';' col_start=... col_stop=... type='ome:category_group'/>
    <entry fieldid='foo'>my value</entry>

other options: straight RDF (performance?)

ilya's sugg of build/install time feedback.
What's for Stefan — search, the status paper w/ kat (the model? -jam)
Shoola timeline (important also for process below)
will send.
search functionality.
drives omero use cases (along with import/resurrect)
get to functionality of 2.5 (lots of bin-services)
Process —
wiki stuff good (should do something)
all work together (consensus)
choose something and try.
no rally/money?


Very Early (see also Wed. notes for <experiment/>
StatefulQuery and StatefulUpdate Handles from ClientSession service
ClientSession session = serviceFactory.getClientSession();
// client session is serialized and sent over. (pre-fill?) all Stateful services get a correlation number.
session.getPojosService().loadHierarchy(); // everything already checked in.

// or just

ClientContext cc = serviceFactory.getContext();
IUpdate u = cc.getUpdateService(); // is actually a StatefulUpdate instance.
ImportEngine ie = cc.getImporter(); // all events should be the same.



history of process
cave dwellers (not as frustrating)


process discussion (then use process for final points)
0. Release plan for ~6 iterations. Usually in production. Estimation like iteration (from previous). Mutable.
Choices will be made as /business/ decisions. Expensive&Important vs. Cheap&Fast.
Defined from previous iterations and "velocity" (how many days per point).
Velocity initially crude.
1. User stories (index cards). Short (few words). Mnemonic. with Time estimate (points).
Find good size for accurate estimates.
2. Wranglers specify points for next iteration. (Iteration perhaps not used.)
3. Stakeholder chooses stories for next iteration within points. No changes on those for 2 weeks.
At this point, the Acceptance Tests are written. (Prior to or concurrent with)
Acceptance Tests in special language written for customers.
4. Wrangler create tasks and plan according to technical needs.
Task is 4-16 hours.
Developers choose tasks (according to personal budget).
and give them task points ("perfect programming hours")
Note: this is good, because DSL for me would be 0.5 for someone else 2, etc.
Here supply and demand takes over.
Note: Assumes a war room.
5. Halfway point. Half of /stories/ are finished -No-> Reapportion, tell customer, lowest priority?
6. End of 2 weeks = new iteration. Customer evaluation of executable. Velocity?
password storage/hashing
Service Stories
Service security should all A (role=admin) to allow B to use agent.
Service sec. should all ... ( "A is privileged in FOO")
IAdmin.addUserToRole(user,role).isUserInRole(user,role),allRoles() // (dyn.)
@Role(Foo) // (static)
Donald writes new agent, and new role "CanDefineTemplate" (in agent.class)
Can define new role. (1/2 static, 1/2 dynamic)
Data Stories
User can run projection queries and not break security (Filters/Interceptors)
User wants full ACL (low prio.)
User makes call and gets filtered list. (No null objects for info. leakage reasons) (or should it be an option "weak security")
User wants to control image resolution.
If possible, do it in method without annotations.
get methods should return SecurityException if necessary (not null)
User would like to protect search. (need interceptor)
Permission should be applicable to whole hierarchy. (IPojos, IPerms)
User can add group (low prio.)

lsid stories

guid needs for client server correlation
guid needed for good equal implementation
lsid needs guid for import / export
implementation: per JVM makeGUID()+System.hashCode()+increment();

donald stories

add annotation hierarchy to D/I/Roi
add annotation hierarchy to everything (RoiRelationship)
store files (/Attachments)
planRegion and render(pix,t,c,z,x0,x1,y0,y1)
user A attaches Annotation to Image of B. B's image SHOULDN'T be updated.
Annotation Hierarchy
Text -> Html
DiscreteAnnotation ("Enumeration"/"Classification") links to Category
StructuredAnnotation -> Xml & -> FileAnnotation -->
PngAnnotation ("AttachmentAnnotation")
Object Annotation
Query Annotation
Names for "lineage"/"Relationship" table
progeny, lineage, "affects"
<experiment/> and <annotation/> are *very* similar. perhaps unify and use /Attachments.

Document Actions