Diff for "Outdated_Cytoscape_3.0/MiniRetreatThree"

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

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 propos 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)
    • debug (status messages for programmers)
    • informational status messages for user (passive, doesn't interupt the user; user will want to access them, even after task finishes)
    • 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
    • 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)