[DAS] maxbins in DAS1.6?

[Thomas Down]

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

> Yep, it should now be a little easier to tell. Also, the 1.6-compliant
> version of ProServer will only pass the parameter through to a SourceAdaptor
> if the adaptor declares support for it. This is one of the ways I hope to
> encourage compliance with the parts of the spec that usually get neglected -
> i.e. metadata. Ideally clients would work on the same principle, i.e. if
> maxbins is not declared as a capability, it won't be sent in the request.
> More tolerant clients tend to result in inconsistent implementations in
> servers. Another way is that the registry will check for capabilities that
> are supported but not declared. Hopefully we can establish both incentive
> and necessity to describe sources accurately.


Thanks.  I've just patched svn-latest Dazzle so it sends X-DAS-Capabilities:
maxbins/1.0 iff the datasource is advertising support (specifically, if it
implements the TilingFeatureSource interface), so I guess that's now fairly
comparable to how ProServer is behaving?

A couple of issues which come to mind, though:

          1. This is all dependent on multiple-datasource servers being able
to return differernt cap-sets for different datasources.  Dazzle already has
the plumbing for this (and, in fact, has returned different cap-sets for
reference and annotation sources for a long time now), but I don't actually
see anything in the spec. which explicitly allows this.  Might be worth
stating that capabilities are per-datasource?

           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?

          Thomas.