Re: [search-ws] [Issue] Server should not be asked to maintain clientstate

[Ashley Sanders <a.sanders@manchester.ac.uk>]

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