[DAS] Adjacent feature extension

[Jonathan Warren]

On 7 Mar 2011, at 11:19, Andy Jenkinson wrote:

> On 7 Mar 2011, at 10:57, Jonathan Warren wrote:
>
>>
>> My vote would ideally to change feature_by_id to return one feature  
>> and have the adjacent_feature as returning one feature. This in my  
>> opinion would mean these capabilities on servers do "exactly as  
>> they say on the tin" and would be easier to implement for data  
>> providers and are thus more likely to be implemented?
>> If the feature_id capability as it stands is needed it could be  
>> changed to something more akin to what it means like  
>> feature_id_region but I would bet no one would bother to change it/ 
>> use it?
>>
>> However the reality is that we are too late to change the old  
>> feature_by_id, but I don't think we need to make the same mistake  
>> twice by repeating it for adjacent_features?
>
> I disagree. I think the problems with feature-by-id are that a) the  
> name of the capability implies singular, and b) the concept itself  
> (i.e. getting a feature by its ID) is such a common operation that  
> is otherwise missing in DAS. I don't think either of those apply to  
> an "adjacent" capability unless you specifically choose to call it  
> "adjacent-feature" as opposed to "adjacent-features". I honestly  
> don't think a capability called "adjacent-features" with a query  
> structure like "/das/features?adjacent=foo:1" implies singular,  
> rather the opposite in fact. To me that query suggests "get me the  
> features adjacent to foo:1". True that 2 features is plural which  
> still leaves a "one feature either side" interpretation possible,  
> but IMO certainly not implicit enough to stop anyone implementing it  
> to actually read the specification/documentation. Add to that the  
> fact that this is an entirely new behaviour that we have the chance  
> to properly document and make it clear exactly what the server must  
> do.
>
> So IMO we have a clear choice.
I still think it's simpler to implement it for one feature either side  
and keep complexity in the client. Generally how many people stay wake  
after line 10 when reading the spec? :) Lets see if there are more  
votes...
>
> As to feature-by-id, I know changing behaviour is potentially a very  
> disruptive change, but I think we can potentially do this purely  
> because servers don't tend to implement it correctly anyway. Clients  
> can happily filter out any additional features returned by old  
> servers, and if any clients are reliant on the server including all  
> overlapping features then as far as I am concerned they are either  
> a) targeting specific servers rather than DAS-wide and thus  
> unaffected, or b) already broken :)
So you agree feature-by_id should be changed if we have the stomach  
for it? - good and Gustavo too. Well done Andy - You have just agreed  
to write Spec 1.7 or 3??? ;) Your argument above can be used for  
leaving the spec as it is then as well - but ideally I agree and guess  
we can call it spec 1.61 assuming other people agree.
>
> I have to admit that the feature-by-id capability is one of the  
> (many) things I loathe having to explain and would love to change  
> it. Doing so would be consistent with what we were trying to do with  
> 1.6 (i.e. rationalise existing use of the spec) but I chickened out  
> really.
>
> Cheers,
> Andy

Jonathan Warren
Senior Developer and DAS coordinator
blog: http://biodasman.wordpress.com/
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.