[DAS] maxbins in DAS1.6?

[Jonathan Warren]

This information should be provided in the sources response from a  
server and is also provided in the registry sources response.
If I was writing a client I would make use of the registry as many  
sources do not implement the sources command.

This is one reason why we often consider making a souces response  
compulsory for registration. However as the registry provides this  
info it is almost overkill to have it twice.

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?
>
>           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.
> _______________________________________________
> DAS mailing list
> DAS at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das

Jonathan Warren
Senior Developer and DAS coordinator
jw12 at sanger.ac.uk
Ext: 2314
Telephone: 01223 492314







-- 
 The Wellcome Trust Sanger Institute is operated by Genome Research 
 Limited, a charity registered in England with number 1021457 and a 
 company registered in England with number 2742969, whose registered 
 office is 215 Euston Road, London, NW1 2BE.