2010-11-09 Tuesday Meeting
Attending: Brian, Andrew, Colin, Scott, Chris, Will, Jean-Marie, Josh, Melissa, Brian Jones, Donald, Ola (Jason joined late)
Agenda
Remember: Agenda must be complete (with estimated times) on the day before the meeting. Any additions after that must go at the bottom (AOCB)
Accepting minutes from last meeting
Matters Arising (<10 mins)
- Add mention of performance issue to troubleshooting
- Organize the troubleshooting page (PG 8.2 etc.)
- Everyone test new password change page in Web (new scenario incl. ldap!)
- Chris: add #3199 to Known Limitations
- Everyone: Its now OK to move any non-critical tickets to unscheduled as long is they are also added to "Known Limitations"
- Everyone: test insight new panel layout
- Andrew: Move troubleshooting page and create new Known Issues/Limitations page - done
- Brian: New screenshots for client documation/list movies that need doing!
-
New scenario: export and re-import
- Brian: Update BF, do import/export testing
- Josh: Contact Shawn G. (email re: protocols/plates)
- Chris: Make a comment about ipv6 on the FAQ
- Josh: writes to angie to arrange travel
- Josh: Update "Known Issues" with using our ice bundle for Mac CPP
Release Status (10 mins)
Ola's Web discussion (30 mins)
Will's EM Web discussion (15 mins)
Any other business (<5 mins)
In Attendance:
- Brian, Andrew, Colin, Scott, Chris, Will, Jean-Marie, Josh, Melissa, Brian Jones, Donald, Ola, (Jason joined late)
Notes
Last week notes
- Accepted
Matters from last week
-
Known issues
- performance (after Chris sees result of last nightshade page)
- no one tested password; chris will do so after meeting
- OME-TIFF issues found and fixed (including schema)
- Document changes ongoing
- Export/Reimport testing had a few hickups with ome.tiffs (fixed now)
- Josh contacted Shawn; no response yet
-
Chris: no FAQ entry to ipv6 yet. on troubleshooting?
- Chris will put it on troubleshooting
- since troubleshooting primarily an installation / getting-started
-
Known issues
Release
- 1 month until ASCB
-
Josh: one issue with bin/omero admin diagnostics
- points to many small changes that are untested
- Jean-Marie: if we can test as much as possible before Thursday
- Chris: @branch tomorrow, get the version number correct
Web Discussion
-
Portal
- Allow administrator to build on widgets/gadgets
- Implement our widgets
-
Scott: extend OMERO.scripts to gagdets
- Ola: could be, depends; haven't really considered that
- possible to have server render gadgets for you
- or handle that in another layer
- Could easily do, but is it what they need?
-
Will: also allow users to setup portlets?
- Ola: for everyone. based on policies
-
Carlos: two different concepts that are mixed
- iGoogle: page that allows you to customize their looks; just another web view
-
provide plugins that users in institution can use in their own development
- e.g.: "agent" for automatic tracking of features
- Ola: have to make sure that we are a platform for publication
-
What are the current requirements for portals?
- Missing: GUI/WYSIWYG, mashups, ~calendar & ~sharing (for users)
- Missing: change css, wiki analytics (for admin)
- Requires a lot of investigation to not get us into a dead-end
-
Portal
EM Discussion
-
This is not stuff from Will's core project, overall impressions of gateway
- nightshade.o.org.uk/webmobile for example
- also mage.../webemdb/
- also experimented with EMAN2 extensions to image viewing
-
webfigure: similar to the figure script dialog on the web
- copy url to send figures to others
-
split-dataset: request from Martin in Paris
- allows quick comparison of channels/rendering defs
-
webroi
- cF. MPorter's matlab code. Very UI oriented (as opposed to scripting).
- might be possible to redo much of this in a more web-centric way
- been experimenting with roi-placement, intensity measurement, volume rendering
-
Summary
- Django/jQuery are great!
- omeroweb/gateway easyt to use
- Should omeroweb be the ui for scripting services?
-
Recommendations
- unify the API (all python clients through blitz gateway?)
- move script utils into blitz gateway
- roi & scripting services in blitz gateway
- more web client resources needed!
-
Q: (Ola) slide 5 - when did you do this? It should be released!
- Will: done while in Australia
- Jean-Marie: needs to be documented/communicated somewhere.
-
Comments:
-
Chris: Classical problem we've had: 'What is the web suppose to do?'
- User-focused/template driven "display" v. adding more functionality as in insight
- Is there / will there be anything in web that's not in insight?
- What happens when/if we make the decision to do something in web that insight doesn't do?
-
At the moment, web is a viewing-centric place. But these proposals could shift to web as primary tool.
- Open questions: import, etc.
-
Jean-Marie: webmobile is a good example of web functionality
-
are we using the potential of web? anything web-specific?
- e.g. something that opens us to the wild.
-
are we using the potential of web? anything web-specific?
- Ola: coming to point where two applications are competing. We shouldn't compete.
- Chris: what's the strategy for integration?
-
Jean-Marie: primary users of the web are ascb/jcb/emdb. Data in the wild.
- Chris: but there are people that want to see all of insight in web.
- But we have to make the decision to do one thing or the other
- Jean-Marie: embed java in browser?
-
Carlos: personal view (biased toward publishing environment)
- web can't replace insight without applets
- point-n-click manipulation of the image will never be as snappy
- no one wanting to interact with the image will be bugged with web-only
- web-only approach is great if you want to be accessible to everyone and their cats
-
Chris: portal-style approach has issue of having the components talking to one another
- Ola: if we spend enough time, framework can provide you handlers
- Jean-Marie: we need to have a clear vision before we embark on new technology.
-
Josh: My 2-cents is that the web is giving good functionality now.
- We should also encourage small extensions like Will's tools as well.
- Jason joined
- Jean-Marie: Don't want to give mixed messages to community
-
BrianJ: my view of .web client
- if you look at deploying OMERO across an entire institute
- all of the people who aren't doing research (maybe at least half)
- need or want to have access to image data - .web is used for this function
-
Jason: is the question how much analysis functionality?
- question is the philosophy, who is the client for. (publishing, etc.)
- Chris: trying to see what we have and come up with a philosophy to explain "why isn't X in client Y?"
-
Will: my philosophy is they should have same functionality
- only reason not is because it's technically too hard in that tech
-
Jean-Marie: fine, but we do not provide the URL clicking in insight
- So, we may focus on merging some stuff, but then we don't take advantage of tech Y.
- Chris: insight has been around longer. Moving forward, if we don't have the philosophy, hard to make these decisions.
- Will: with my philosophy, it's easy to decide which (all) but not to prioritize them
- Jean-Marie: Brian's comments about big institutions may help to prioritize
-
Could this make a change in getting OMERO into an environment?
- BrianJ: Not a key factor in their decision
- But moving to OMERO is a major paradigm shift which goes up to senior management
- Want to make technology / tool available to the entire institution
- But don't want to deploy Java/Insight to every desktop
- i.e. frosting / an important element in the discussion
-
Jason:
- saying broadly similar things in different ways (Chris: ?)
-
biggest problem technically is that there are things completely not exposed in strict subset of clients
- e.g.: share, rois
- Ola: this is because we don't have the strategy
-
Chris: Will is right, they are too polarize; there isn't enough overlap
- Even if we restrict Web, we'd still have to port functionality
-
Jason:
-
will every piece of data be visible in both? (less about the users, then our offering)
- Chris: for the moment, I'd say yes.
- Ola: everything in the model should be visible, maybe not editable
- then ask: how will clients be used by institutions?
-
will every piece of data be visible in both? (less about the users, then our offering)
-
Jean-Marie:
- need to learn from our usability testing, and try to see data in a similar way
-
Josh: it might make sense to use the gateways to gather up functionality between clients
- Gateways could be used to 'hide' the difference betweeen implementation and model
- Jean-Marie: Good name for this is the 'communication layer'
- e.g. there's no API that does "cut"
-
Jean-Marie: time contraints will make this sort of unification difficult
- Need to make a lot of these agreements before implementation to get this working 'in the future'
- Josh: Long term goal to ease getting new developers on-board, etc.
-
Carlos: Some framework in place for web 'api scripting service', maybe a good place to start
- discussion needs to happen in person
- Jean-Marie: may then also look at the interfaces
-
Will:
- commit?
- Jean-Marie: after branch.
-
Chris: there's a lot of low-level infrastructure missing, and documentation about how things should be structured.
- "In url.py don't do these X things, because you will cause problems"
- similar to making an Insight agent.
- We have to stop working so wild-and-free to have this stuff extensible.
-
Jason:
- should we talk to someone like Mark at Imperial who's developing in this environment?
- probably a lot of overlap. and changes will inevitably cause him some pain.
- Will: he would benefit a lot from some of this development.
-
Chris: where are the boundaries?
- importer: someone finds a methods and starts using it. we change it, and boom.
- the same thing will happen in the web: change to some templates makes others' code break
- for mark: do you want to be hacking on the OMERO code or on a layer up? (not necessarily extant)
-
Ola: we should have some kind of framework, even if really simple
- Chris: starts at the low-level
-
Jean-Marie: Outcome?
- More discussion? More need for low-level web work?
- Chris: if we made the decision to unify the data display, that's a lot of work.
- Also need anonymous access: insight and web
- Puts off our philosophical discussion until everything displayed and framework in place
- Otherwise, can't discuss what other components to put in
- Already pushing us towards "publishing" realm.
- Then we can discuss portlets / user-controlling display
-
Jason
- impression of 4.2.1: awful lot of good functionality
- good time to say "let's go back underneath"
- big problems that were hurting us (permissions, delete) are fixed
- can now discuss flim analysis, etc.
- good foundation that we can have out there for a while
- and then see what we need to re-architect
- "anonymous access" + big images is a good start.
- Jean-Marie: new permissions requirement
-
Chris
- push it in the direction of publishing: anyonmous access
- then see where we are.
- we've enabled collaboration, now we need to make it useful & easier
-
Chris: Classical problem we've had: 'What is the web suppose to do?'
-
This is not stuff from Will's core project, overall impressions of gateway
Other Business
- None
# Actions # * Add "display all data in web" requirement * Add "anonymous access" requirement (~6 mon. work) * Add "web framework" requirement * Add flexible group/projections requirement