On 28 Mar 2011, at 10:36, Leyla Garcia wrote: > On 23/03/2011 16:23, Andy Jenkinson wrote: >> On 23 Mar 2011, at 15:43, Gustavo Salazar wrote: >> >>> Hey Andy, >>> I think we didn't discussed if empty segments should be included. In the >>> implementation I got I am not including those, I think is not necessary. >> That's fine, it makes the implementation easier too. >> >>> I think the agreement was to report the error as an HTTP error, but that >>> was though more in the perspective of clients that are not supporting this >>> capability, trying to avoid servers responding paginated segments when the >>> rows attribute was not included. > Gustavo, do you mean segment= and nothing after the =? For features and > segment those are reported as an ERRRORSEGMENT for myDAS. We will keep it in > this way, right?
No, I'm talking about something different here... this is for the cases that the response is too big that the server wont be able to response. We considered the option of doing a pagination forced by the server, even if is not requested, however it might confuse clients that are not supporting this capability and these may think they are getting all the results. Thats why we decide to go with a HTTP error approach + X-DAS Status. The "segment=" case was not discussed here, but Andy told me a while ago that he will include some descriptions about this case in a future amendment of the spec 1.6.1 > Leyla >> Absolutely, that's good. >> >> I've updated the wiki with clarifications of these points, and an example >> response illustrating how the server should choose which rows to return. >> >>> Cheers, >>> Gustavo. >>> >>> >>> On 23 Mar 2011, at 15:01, Andy Jenkinson wrote: >>> >>>> Hi Gustavo, >>>> >>>> Thanks for this, looks fine to me mostly. >>>> >>>> One question: should segments that contain no features (due to the >>>> pagination limit) be included in the response? >>>> >>>> /das/foo/features?search=a*;rows=1-2 >>>> >>>> <GFF total="300"> >>>> <SEGMENT id="1" total="40"> >>>> <FEATURE id="a" /> >>>> <FEATURE id="b" /> >>>> </SEGMENT> >>>> <SEGMENT id="2" total="30" /> >>>> <SEGMENT id="3" total="90" /> >>>> ... >>>> </GFF> >>>> >>>> Also, I can't remember if we decided at the workshop whether servers would >>>> be allowed to overrule the client's requested range and return (for >>>> example) a smaller number of rows. This is how entry_points works, which >>>> is why it has "start" and "end" attributes in the response in addition to >>>> the "total" attribute. >>>> >>>> On 23 Mar 2011, at 12:08, Gustavo Salazar wrote: >>>> >>>>> Hello all, >>>>> >>>>> Following the momentum that the DAS workshop let us I started tackling >>>>> one of the many projects that we defined during the 3rd day: The >>>>> pagination for the features command. >>>>> I added the proposal for the extension in the wiki: >>>>> http://www.biodas.org/wiki/DAS1.6E#Pagination_for_DAS >>>>> I have implemented it in MyDas and is included in the snapshot version of >>>>> the repository in case anyone wants to play with it >>>>> http://mydas.googlecode.com/svn/snapshot-repository/uk/ac/ebi/mydas/mydas/1.6.5-SNAPSHOT/ >>>>> As a nightly version it may have changes whenever we do a release after >>>>> some proper testing of it >>>>> >>>>> Looking for your feedback about it! >>>>> >>>>> Cheers, >>>>> >>>>> Gustavo. >>>>> _______________________________________________ >>>>> DAS mailing list >>>>> [email protected] >>>>> http://lists.open-bio.org/mailman/listinfo/das >>>> >>>> _______________________________________________ >>>> DAS mailing list >>>> [email protected] >>>> http://lists.open-bio.org/mailman/listinfo/das >> >> _______________________________________________ >> DAS mailing list >> [email protected] >> http://lists.open-bio.org/mailman/listinfo/das > > _______________________________________________ > DAS mailing list > [email protected] > http://lists.open-bio.org/mailman/listinfo/das _______________________________________________ DAS mailing list [email protected] http://lists.open-bio.org/mailman/listinfo/das
