[DAS2] Minutes from 16 Oct 2008 DAS teleconference

[Steve Chervitz]

Notes from the biweekly DAS/2 teleconference, 16 Oct 2008

$Id: das2-teleconference-2008-10-16.txt,v 1.1 2008/10/30 02:42:50 sac Exp $

Teleconference Info:
   * Schedule:         Biweekly on Thursday
   * Time of Day:      9:00 AM PDT, 12:00 PM EST, 16:00 GMT
   * Dialin (US):      704-687-8984

Attendees: 
    Free agent: Gregg Helt
    Affymetrix: Steve Chervitz
    EBI: Andy Jenkinson
    Sanger: Jonathan Warren
    U North Carolina: Ann Loraine, Steven Blanchard, John Nicol
    U Utah: David Nix
    LBNL: Suzi Lewis

Note taker: Steve Chervitz

Action items are flagged with '[A]'.

The teleconference schedule and links to past minutes are
available from the Community Portal section of the biodas.org site:
http://www.biodas.org/wiki/BioDAS:Community_Portal#Teleconference

DISCLAIMER: 
The note taker aims for completeness and accuracy, but these goals are
not always achievable. So don't consider these notes as complete minutes
from the meeting, but rather abbreviated, summarized versions of what
was discussed. There may be errors of commission and omission.
Participants are welcome to post comments and/or corrections to these
as they see fit on the the discussion list.

========================================================
Agenda: 
* Das1/2 integration
* Security and auth
* Proposed spec changes

Ann: I volunteered to look into getting RCN funding - haven't done
anything on that.

Gregg: Suzy, Me and Ian (Holmes) will submit something in Feb. With
Suzy as the PI. Also, she mentioned that Gmod help desk would get
involved. 

Suzi: This will keep us to 3 institutions, better than 4 -- too
disconnected.

Gregg: combined Sanger, EBI, South Africa network submission
(December).

Andy: Still going ahead. Working on adding writeback.

[A] for Suzi: Decide if it be Ian or Suzi as PI. Can issue reciprocal
letters of collab.

[A] for Steve: Combine das and das2 lists. Can they be merged.
Check into best way to do this: bounce with message to repost, or
automatically forward anything sent to das2 to the das list
(better). Also: make steve admin on das list, add members from das2 to
das1

Gregg: Important to recover the early discussions

Lincoln (not on this call) is on paternity leave (10/11 girl)

Ann: Ad hoc meetings or regular?
Consensus: regular

Suzi: q for sanger/EBI - how many people would care about das spec?
Doesn't sound like all stakeholders are on the line.

Andy: Quite a few do, but not all can find time to participate. quite
busy. I will serve as their representative for these calls.

Topic: Authentication
===========================

David Nix: Security and auth. What's going on with that?
Summary: I work in core facility, get requests to process data,
private, to be hosted on das server, return to PIs, log into das
server and retrieve data. I hacked into genoviz das2 server a way to
do it, not built into spec, but is really needed. Want to compare
private tracks to public.

We have many diff groups with diff folders, each needs diff permission
settings (lab only, lab + collabs, organization only). Came up with a
custom solution on the das2 servlet rather than a standard http-based
authentication route.

One possible approach: Issuing a special types request suited for that
person. 

GH (Gregg): We only used http auth, worked for us, but is all or none access
to a das source. differentiating based on types w/in an

Steven (UNC): Looking into http authentication. have a test
running. can do arbitrary auth for certain types but not others. Can
force it on a query parameter.

GH: Tomcat realms etc. looking into this.

Steven: Can't to that. Need to create a servelet filter, can send back
a 401 on any server you want auth on.

Nix: Concern: for some labs, they want to keep the genome they're
working on to be private. Do you have to make a request for the track
before you're allowed to see it (e.g., dnase footprinting track)?

steven: challenge response, so server would leak track names. But you
can hide tracks from users if they're not authenticated. Comes down to
the implementation side, not the spec.

GH: running multiple servlets problems could be because of gregg's
implementation. Should be no problem for diff servlets running in same
tomcat. Genometry server was impl under assumption that it's data
model might be shared between diff servlets. Might need to be fixed.

Nix: I have >30 folders. Running so many diff servlet instances would
be insanity.

Concerned about management of permission files. Want someone to
administer via webpage, not a sysadmin. Want to enable lab managers to
add users, change permissions w/o having to send requests to
core lab developers/sysadmins.

Steven: Policy file is java policy file (Using jazz for security
framework). Have flexibility of where policy info is stored. Could be
managed via database.

UK folks security needs?
Intend to use openId system to do authentication. Permissions would be
downstream from authentication. Permissions attributed to different
users haven't been addressed yet. Two separate issues.

UK: Auth is performed by delegate servers.
works across the whole system, rather than having server-specific

Das registry uses it now.

GH: Security/auth is orthogonal to the spec. should be kept separate.

UK: Expectations should be indicated.

Steven: Spec should say that it supports protocol somehow, but not go
into implementation-specific things.
E.g., Do you need to authentical before you can see anything

UK: Good thing about OpenID

Steven: Worry: most client libraries and langs do not support it, whereas
http
auth is more widely supported.

Suzi: There won't be lots of people writing clients, just lots of users.

GH: Concern about putting anything about seecurity and auth into the
spec, adds more to debate about. We've got 3-4 different options
already. Would like to keep it out of the spec.

Suzi: The need is there given interest addressed here. We should say
something about it in the spec. Need to pick one.

UK: Anyone reviewing this proposal will ask about it.

[A] for someone: Need a summation of the pros and cons, bite the bullet and
choose
a path. Need a person to review descriptions and make a decision.

Ann: Would be good to have a statement of pros and cons of different
positions. But yes, a final decision should be there.

Suzi: Someone else could review/summarize a different person's
suggestion.

UK: Agree.

Suzi: I will be reviewer.

[A] Gregg will forward our off-list discussions to the list to get input
from others.

Nix: Don't care so much about impl. Really need a way to formulate a
custom response to an individual. Would be great solve via best
practices. 

SC: Security/auth will be very important with the growing interest in
personalized medicine. Great to get this nailed in the spec.


Topic: Das1-2 spec merging
===========================

GH: Has everyone had a chance to review Andy's writeup?

Suzi: Anyone gone through point by point to see where diffs lie?
GH: Yes. While at Sanger. Meeting about making changes to das 1.5
spec. Talked about hybridizing them. Have side-by-side UML models.

[A] Gregg will send out side-by-side UML models (pictures and/or model
files).

GH: Re integration: Andy said biggest issue for sanger/ebi/biosapiens
is backward compatibility (lack thereof) for das2

Suzi: what pieces in das2 spec are not backwards compatibile? Which
features that are fundamentally different?

GH: working on making das1-> das2 proxy. Very aware of the diffs:
Summary: (see das plan from Jonathan and Andy for change needed to
das1.5 spec)
1) the notion that everything has unique URI in das2  (das1 things
   have
2) hierarchical features
3) Location spec of features (0,1, many) covers gene das and das1
   alignments. We condensed down the alignments into annotations that
   have potentially multiple locations, Bridging these can be
   challenging.
4) Alternative content types. Negotiated between client-server. Enable
   returning back much more efficient format than xml.

Suzi: could that sit on top of something than can/can't negotiate?
GH: Maybe. But gets to backward compatibility. Changing optional <->
required breaks compatibility.  E.g., saying you can ignore anything
you don't understand.

Jonathan: Non lossy conversion? Important for getting people on
board if it is lossy.

GH: Forward from das1->das2 is possible. Das2 allows injection of
arbitrary xml (which can be das1 xml). Not possible in reverse
direction. Looking into proper translation into das2 elements and also
preserve das1 xml.

Suzi: Motivations are still the same. Revisiting the specification, we
all have same issues. Ability to deal with hierarchical data. Seems
very important. Should be translatable non-lossy.

GH: Not translatable in a std fashion. It's a standard you'll have to
force on top of das1 spec to achieve this.

Suzi: Motivations for changing where we are, are the problems we're
trying to solve the same (for 1.5 or 2)?

GH: Main dichotomy is mainly proteins vs genomes vs genes. Stuff built
in das2 may not be appropriate for proteins (slices of annotations on
a range -- you want all of them). Similarly regarding types, might want a
better
breakdown of things without sending all proteins.

Andy: Not many diffs in what we're trying to achieve. Need to
determine whether we want to change a server to support a
protocol. Much more difficult. Once we solve the gaps in das1. Need a
way upgrade without a complex process, w/o using das1 proxy.

Suzi: not a viable long-term solution.

GH: Hard to make tweaks to a spec that uses XML the way that Das1
uses it w/o breaking ba
gene das says you don't need start/stop. Takes two required args and
makes them optional. E.g., my client assumes there's a start and stop
so will break.

Andy: Will still process the request...

GH: Disagree for gene das. Send a query asking for all feats, and you
get something back w/o start-stop.

Andy: Far fewer clients than you have servers. Changing servers is
harder than clients.  Different degrees of "breaking".

Suzi: you mean implementations, right? Might be more instances of
clients running, but more different types of servers?

Andy: Fewer client installations than there are servers, since most
clients are web based.
Suzi: I was counting all web based ones as well.
UK: Using Java web start, clients can be updated automatically.

Suzi: How move forwared.

GH: Implementing das1 proxy, to help people (and self) be aware of
the differences. Posted code to Google code proj. Project=Genomancer
(necromancer for genes!)

[A] gregg - write proposed changes to sources document more formally.
Sanger/EBI are working on 1.6 which includes sources. Rev das2 to have
more updated source command as well.

Jonathan, Andy: [Lots of chop on the phone line] Validation for
registry using XSD. Also ddding requested features to the das
spec. Need to see where it's being used.

Suzi: We want to have one single spec.

UK: Right.

GH: RelaxNG for the sources command?

UK: Just started. haven't used it before.

Someone: Why using XSD?

Andy: Need better validation. Newer commands using XSD, since no one
is using DTDs.

Suzi: Why not consider RelaxNG. I used to be a XSD person, but have
become a fan of RNG.

UK: We can look at it.

GH: Andrew (Dalke) convinced me to use RNG and I've been pleased. XSD
is difficult to read/work with.

UK: It's not too late to change it.

Suzi: We want one spec. Treat it like a football. One person holds it
at a time. pass it back and forth. Multiple editors can be a
problem. Need to be sympathetic with people who come in with
requirements.

GH: For das2 grant, I appointed Andrew as spec czar. Only he could
make changes to the formal schema, other can change HTML docs. Avoided
conflicts in the schema.

UK: [lots of chop on line]. Doing a small remediation to the 1.5 spec,
then we'll have a spec that can incorporate more of the das2
requirements.

[A] UK folks: Continued Das integration work.

Suzi: One spec czar + multiple html editors.
GH: I gave Andrew veto power, but if he abuses it, we'd depose him!
GH: Needs to be called something different. Das3?
Suzi: no! 
UK: Just DAS?
Suzi: Yes, "Das", with releases.

[A] Anyone interested in contributing: look at links from Andy/Jonathan on
how das1 is changing.

Ann: Das2 spec for making changes to genometry server. How to edit
this doc so changes can be rolled back in?  HTML.

GH: Steve?

SC: Yes, I can work on wikifying the existing DAS HTML spec on the
biodas.org wiki.

GH: Like the idea of wikifying them. Next week?

Ann: Stable HTML version + separate live document

[A] Steve wikify the HTML docs.

John (UNCC): Genomancer code is up to date?

GH: Yes, but not usable yet. Das2 -> das2 proxy ok, but needs
docs. But das1-> das2 is not functional yet.

SC: What's purpose of das2 to das2?

GH: das2->das2: can do lots of interesting things: Inject alt content
format. Serve json from a single das2 point. Lots of stuff...

[A] All: Teleconf in two weeks, same time, but need better phone line!



------------------------------------------------------------

This transmission is intended for the sole use of the individual
and entity to whom it is addressed, and may contain information
that is privileged, confidential and exempt from disclosure under
applicable law. You are hereby notified that any use,
dissemination, distribution or duplication of this transmission by
someone other than the intended addressee or its designated agent
is strictly prohibited. If you have received this transmission in
error, please notify the sender immediately by reply to this
transmission and delete it from your computer.