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