[DAS] maxbins in DAS1.6?

[Thomas Down]

On Tue, Sep 15, 2009 at 2:34 PM, Andy Jenkinson <andy.jenkinson at ebi.ac.uk>wrote:

>
>           2. For some DAS clients (including the one that currently
> interests me), it's quite likely that a "features" request might well be the
> first contact the client has with a given server.  But until that first
> request comes back, how does the client know whether maxbins is appropriate
> or not?  Right now, I'm probably going to just go ahead, stick maxbins on
> the first request, then leave it off subsequent requests if the capability
> is missing from the first response, but that isn't really a good fit to your
> "strict client" principle.  I suppose the ideal would be some kind of fast
> "pre-flight" request that can be issued to check a datasource's cap-set, but
> it's not totally obvious what to use.  A dsn/sources request is definitely
> no use here, if capabilites are per-datasource.  'types' might not be a bad
> idea, but I'm a bit reluctant to depend on it because, at least in the past,
> it's not been widely used (and can be a bit slow if servers want to return
> type-counts but don't have an efficient way of calculating these).  I
> suppose 'stylesheet' might be to logical choice.  Or just 'features' on a
> 1-base segment.  Or am I missing something?
>
> Capabilities are stated in the sources document:
> <CAPABILITY type="das1:maxbins" />
>

Ah, interesting.  I'd seen that, of course, but hadn't explicitly linked
this with the idea of capabilities as listed in the X-DAS-Capabilities
header (although of course it makes a lot more sense to have one set of
capability metadata, rather than two!). There are a couple of issues here:

            1. The SOURCES examples all say "das command" in the type
attribute of the CAPABILITY element, whereas many of the capabilities don't
actually map to commands.  I notice that the latest DAS1.6 draft does give
an example to clarify this.

            2. X-DAS-Capabilities entries are versioned whereas SOURCES
capabilities aren't, which makes them look rather different. (and I note
that the 1.6 spec is bumping up the version numbers on some of the existing
capabilities...)

How about versioning capabilities in SOURCES, e.g.:

         <CAPABILITY type="features" version="1.1" query_uri="
http://noranti.derkholm.net/das/mydata/features" />
         <CAPABILITY type="maxbins" version="1.0" />

Assume any missing version attributes are "1.0" and everything should be
backwards compatible.


> The only snag is that right now you have to parse all sources. Technically
> both the registry and proserver allow you do do:
> http://www.ebi.ac.uk/das-srv/genomicdas/das/sources/eqtl_rat_cis_fat
>
> But IIRC I didn't include this in the spec to keep things simple.
>

If this isn't specified yet, how about allowing:

             http://www.ebi.ac.uk/das-srv/genomicdas/das/<http://www.ebi.ac.uk/das-srv/genomicdas/das/sources/eqtl_rat_cis_fat>
eqtl_rat_cis_fat/<http://www.ebi.ac.uk/das-srv/genomicdas/das/sources/eqtl_rat_cis_fat>
sources<http://www.ebi.ac.uk/das-srv/genomicdas/das/sources/eqtl_rat_cis_fat>

?

Then it's possible to stick with the model of passing a single URI around to
refer to a "DAS datasource", and stick a command on the end of it to get the
data you're after.

               Thomas.