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
<[email protected]>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
[email protected]
http://lists.open-bio.org/mailman/listinfo/das
Jonathan Warren
Senior Developer and DAS coordinator
[email protected]
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.
_______________________________________________
DAS mailing list
[email protected]
http://lists.open-bio.org/mailman/listinfo/das
