[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [search-ws] [Issue] Server should not be asked to maintain clientstate
Farrukh Najmi wrote: > To redefine a cliche my mother use to say to me as a teenager "would you > jump in the well if your friends jumped in the well", That is good advice to keep in mind before jumping down the well that is REST and Atom. > You make an implementation assumption above that to fetch 2 windows > (ranges) of records as server must fetch all the data and return a subset. > Most implementations I know tend to use features of databases that allow > fetching inly the records for a specified range of indexes. In such a > (typical) > implementation there is no waste in make two separate queries in > response to two separate requests that execute the same query but with > different range indexes. You are also making implementation assumptions. > To summarize: > > * There is a distinction between application/client state and > resource state > * Maintaining client state is clearly against REST The spec is not requiring the server to maintain client state (which is what I think you saying above.) > * Experience of most experts on scalability is quite clearly > suggesting that a stateless application is more scalable. > * The suggestion that stateful handling of paginated searches is > more scalable is based on a implementation specific assumption In our case, it is not an assumption, it is an implementation fact. > that does not apply to most implementations that use features like > SQL language features LIMIT/TOP/OFFSET You seem to be implying that everyone should use SQL and "language features LIMIT/TOP/OFFSET" and if they don't well it's hard luck for them because we are going to ignore their needs. And anyway, doesn't it all depend on user behaviour and how expensive it is to run the query on the server? If the vast majority of the queries you need to handle are simple 1 or 2 term keyword searches and the users never go past the first page of results then I guess a REST approach is going to suffice. However, such user behaviour is not always the case and queries are not always inexpensive in terms of CPU and disk access. I don't think we should be making any assumptions about server implementations, but neither should we be stopping anyone being able to implement a stateful server if that suits their requirements. > * We have normative but optional features that require server to > maintain client state > o In this issue I propose eliminating those features (optional > or not) as they encourage questionable design > o If an implementation wishes to provide the feature let that > be outside the spec and implementation specific As has already been stated, the features to which you refer DO NOT REQUIRE the server to maintain state and therefore there is nothing that needs eliminating. Ashley. -- Ashley Sanders a.sanders@manchester.ac.uk Copac http://copac.ac.uk A Mimas service funded by JISC
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]