[DAS] maxbins in DAS1.6?

[Andy Jenkinson]

On 15 Sep 2009, at 13:43, Thomas Down wrote:

> 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?

ProServer also does this, I think this is probably one of those areas  
that when you're immersed in using it on a daily basis like I am seems  
obvious but actually is not! The 1.6 spec has slightly more  
explanation of the server/source paradigm, and I will add some  
examples to the 'capabilities' section to illustrate that the  
capabilities in the header will depend on the request. I can already  
think of one possible area of ambiguity - it is not stated that data  
sources shouldn't report support server-level commands (i.e. the  
sources and dsn commands).

>            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" />

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.