[DAS2] how to test features?

[Andrew Dalke]

Ann:
> If you go with a limit option, you might also consider including an 
> sorting option, as well.
>
> This would be useful to screen out low-scoring blast hits, for 
> instance.

That makes the interface a lot more complicated because
the sort order can be different than the request.  Eg,
"all X sorted by Y".  Even worse, it could be "sorted by
Y (collated as strings) and break ties by reverse order
of Z (collated as numbers)."

A thick client could still implement the sort of course,
though at the cost of higher overhead.

One proposal I made years ago was a two-part request,
the first to get a list of feature identifiers, the
second to get the information about a feature.  That
is, /feature?whatever returns

<HITLIST xml:base="features/">
  <F id="A1" />
  <F id="A2" />
  <F id="A3" />
  <F id="B" />
</HITLIST>

The client would then figure out "Oh, I already have
A2 and B so I only need to fetch A1 and A3."  Then
turn around do a bunch of GET requests for the missing
fields.  One  problem with it is that to get high
performance requires using HTTP/1.1 pipelining.

(Another possibility is a special API to fetch a
bunch of features given its URL id, but something feels
wrong about it; don't know why though.)

I mention it now because the feature hitlist would
be relatively small even if all features are returned;
there's about 10 extra bytes per name and it compresses
well.

But that need for pipelining is a big limitation.  I don't
know if it can be done even in the Python libraries I'm
used to.  I think it can, I'm just not sure.  I don't have
the experience, and there's the extra requirement for
perl and java client/server support.

It wouldn't help the sort problem though, except by
downloading everything into the client.

					Andrew
					dalke at dalkescientific.com