Mini-Retreat Three

March 6-7, 2009

ISB, Seattle WA

Logistics

Flights: arrive Thursday night, depart Saturday evening

The Official Hotel!

The Watertown Hotel in the U District has ISB rates (mention ISB): http://www.watertownseattle.com/

They also have a free shuttle to and from ISB apparently.

Transportation: Shuttle from aiport to hotel (sad to say we have no decent public transit yet). Shuttle to and from ISB/hotel, there are also bus routes. Should anyone choose to stay in a downtown Seattle hotel Sarah could arrange to pick you up/drop you off. Can only take 3 though (and no one else here drives).

Schedule: THUR - nothing planned. If people would like to meet for dinner/drinks we should arrange that by Wednesday and Sarah will send cell phone number to you.

FRI - all day meeting. Breakfast at hotel. Lunch in Fremont area or we can order in sandwiches. Dinner TBD.

Meeting Schedule

• Hector & Sarah have a short presentation on web handling (eventing, data I/O etc).

• State of 3.0 - Mike will describe the code as it stands now.
• Come to a resolution on Event bundling
• Discuss IO
• Discuss the Application bundle
• Discuss packaging
• Project Management

Meeting Notes

• Discusson of Cytoscape dependency structure

in general, components will depend upon APIs, not implementations. The implementations are injected at run time. Distinguish via syntactic conventions: '-api' or '-impl

• Work API

Task and Task Factory: uses a pattern that will be commonly used throughout Cytoscape Task: two basic methods, cancel and run encapsulates one unit of work. TaskFactory: created and registered with OSGI as a service Cytoscape takes task factories and makes them available Menu information is metadata Factory takes care of how to instantiate the task. Call to it is a simple getTask() method

• How Spring works

two main XML files context: constructor with OSGI, context registers task as a service

• What exactly Spring do?

Spring defines relation between objects basically its for wiring, constructing instances for injection

• Discussion of handling menu actions as OSGI:services

for the application level, need to take all actions and register them as services tunable as an annotation in the code

• Possible performance implications:
  • OSGi/ Spring might mean some overhead
  • startup appears a little slower, but could do lazy startup: activate bundles only when needed
  • possibly some method call overhead, due to looking up via service
• View API:
  • viewmodel mostly done, view (presentation) not yet; thus you can compile but not test visually (layout algorithms, for example)

• Moving forward:
  • tasks, properties, undo

  • vizmap->view model (dependency on presentation? ideally, no.)

  • presentation (hidden impl first using the old presentation api but the new viewmodel api (just to allow work on other parts, for example layouts), then rework presentation api)
• Then core is basically formed, and we're ready for:
  • layouts
  • groups
  • coreplugins

after lunch break

Hector's talk on web api plans: (see slides linked from post on cy-staff)

http://docs.google.com/Presentation?id=dgjpcspp_146g9f9jscv&invite=f437tpt

• REST API, stateless server
• will propose GSoC project
• data source implementation considered good idea, but not critical from 3.0; it can be implemented later
• ISB will take lead either with a GSOC project or through other collaborations to see how we could integrate this idea

IO discussion

• create or not create view?:
  • in 2.x, view is not created for large networks, as a speedup optimization
  • in 3.0: create viewmodel for all networks; this should be cheap and fast; presentation might not be created

• Note that presentation will bie tied to the viewmodel somewhat, since presentation defines the VisualProperties (i.e. the columns of the viewmodel) assumption can be made that viewmodel allways exists for each network

• authentication: for https data sources, need for username/password only apparent after a 401 response (i.e. try read, get 401, do auth)
  • in java, common practice is to throw a specific exception to signal that Authentication is needed
  • plan: Reader throws that exception, UI part catches it, and retires after asking username/password (need to ask optional username/password arg to api)

• Perhaps change org.cytoscape.io.read.CyReader so that read() returns a java.util.Map and remove getReadData() and getSupportedDataTypes()

• For plugin developer, how to add a new reader to support graph data type that Cytoscape core does not support. i.e how to extend CyReader?

Application -- logging:

• use status bar (bottom of window) for feedback to user
• are logs only for programmers? Where should recoverable parsing errors be reported? ('I read your file, btw, it had this garbage in it') these should be visible to the users; Should Task support status messages?
• should logging be used to communicate with the user? (Alternative is that Task framework is used for such communication)
• usecases: (active: needs interactive input from user, passive: stays in background, not in-your-face)
  1. debug (status messages for programmers)
  2. informational status messages for user (passive, doesn't interupt the user; user will want to access them, even after task finishes)
  3. warning messages for user (active, interrupt the user, but recoverable errors) -- things the user needs to know about, but doesn't have to do anything about
  4. error messages for user (non-recoverable, user has to be interrupted with it)
• question: should 3 and 4 be part of Task?
• also: will code regularly have to log to two places, writing two messages? -- since one would want different things for programmer and user, this might not be too big a problem.

• an important aspect to consider: if such logging is done in TaskManager, then TaskManager would have to be passed down into all algorithms. log4j doesn't: it can be cleanly gotten a handle on.

• 1 is solved: will pick a logging mechanism and everyone will use that.

• 4 is solved: done by throwing exceptions; TaskManager catches exceptions and shows them as non-recoverable errors.

• big uncertainty is about 2&3 -- most likely: two prototype implementations (one using TaskManager, one using logging framework)

Saturday

Saturday's Agenda:

1. Project management

• -> Architectural document -> Project plan -> Hackathons

2. Discuss web UI

• => Issue: should we care about a web UI implementation? => If we develop a web version, what are the implications for the structure of Cytoscape? => We need a discussion of what design decisions limit us from developing a web UI => Example of web app we want to aim for: Ingenuity

3. This leads into a discussion about events

Project Management:

• do we need 'project manager' (or more granular, 'bugs', etc.) position? -- (yes)
• project manager has no real authority since he is not the boss for most people
• assigning 'module owners' who are responsible for given areas?
  • to some extent, this was done before
• mark module ownership in javadoc (important part is institution, not persion, since programmers might change)
• there is consensus on low-level architecture, so common ground is there
• architecture document:
  • common requirements in a high-level way (what users to support)
  • common infrastructure (like logging package)
  • inlcude dependency graph of modules / bundles, color-coded with owners
  • common patterns
• ISB, and others will write an 'architecture document', and Mike will review / critique it (a few iterations assumed)
• project manager shouldn't have to check every line of code; 'project manager's job is about communication, not about code'
• need a detailed task list (to also include documentation tasks)
• "dividing up the tasks" needs to be done on the institution level, with support from the board (cytoscape consortium).
• commitment has to be done by the institutions, so they (consortium board) should divide up the work
• module owner responsible for given module, reviews every line of code
• [making list of modules in cytoscape network]
• cytoscape consortium board will divide up the work based on the list of modules (and estimated workload)

Events:

• see http://www.cytoscape.org/cgi-bin/moin.cgi/Cytoscape_3.0/EventHandling

• Mike favors adding bulk methods. -- general consensus on adding bulk methods

• NetworkBuilder pattern will be needed for IO implementation;

  • IO framework could explicitly use builders instead of directly using networks, to force io implementors to use builders.
• problem with bulk addNodes() method: would like to seperate node creation from 'add node to network', but this would have problems with unattached nodes floating around.
• there is a consensus on the event handling side:

  • have bulk events (for example NodesAdded), and not adding magic 'event coalescence' in event handling framework.

decision:

• have a createNode() for creating an 'not yet added to network' node (which will be a CyNode subclass), but this node is bound to the given network and cannot be put in an other network.

• current addNode() is replaced with network.addNodes(network.createNode())

• this pattern can be used for other, similar cases, where doing bulk operations will be a common usecase

small note: will have to ensure that full javadoc we want to expose to plugin writers (i.e. the public api) is accessible from one place

Application:

• application is only gui stuff

• has methods to access CyMenus and cytopanels

• drag & drop:

  • cytopanel, and presentations will 'proxy' drag-and-drop events and turn them into from toolkit events (i.e. swing events) into abstract (cytoscape-) events.
  • do we want to have a higher abstraction on top of drag-and-drop (like we will have for other events like mouseclick or gestures on graph presentation)?
    • one question is what do we want to support apart from swing
    • advantage would be less of a chance of having swing creeping into everywhere

UIs:

• possibilities for non-gui ui:
  • command-line
  • communciate using stdin/stdout pipes, passing commands back and forth.
    • web service could be done very similarly

An aside, belonging to the presentation layer: for z-order:

• could put context menu on a given z-order level, for example to put a context menu only for background

Web ui:

• no current usecase for highly interactive "desktop-like web ui", no one has that requirement right now.
• danger of overengineering if we try to make one up
• for 3.0, will do headless cytoscape, this will automatically serve as base for 'cytoscape for web service'.
• we are explicitly not implementing (and not designing for) a tightly coupled client-server webapp (where dragging a node propagates events back to the server)
• this doesn't mean that cytoscape 3.0 won't be a good base for such webapps.

MoinMoin Appliance - Powered by TurnKey Linux