OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

search-ws message

[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 client state


As Ashley already pointed out - this is an optionally supported feature
not mandatory.

The feature here is that of a named result set which has a lot of
history and discussion. When we first started on SRU we had a long
debate over how stateless we could make the protocol.

For a generally static database we can have true statelessness between
requests, i.e. 

I can send a query Q and ask for records 1 - 10. 
I can send the same query Q and ask for records 11-20 knowing that these
will consecutively follow from the previous 10
I can send the same query Q and request sort by author and ask for
records 1 - 5
I can send the same query Q and request sort by author and ask for
records 1 - 10 and know that the first five records will be the same as
in the previous query

For more dynamic databases (e.g. a database of web usage statistics) the
above does not apply, hence a mechanism for sending a query and having
the result set from that query cached so that it can be referenced
later.

Moreover, as Ashley points out, named result sets can actually make
things more scalable - the scenario of sending a query and asking for
the first n results, followed by asking for the next n results is very
common, and the overhead of storing a result set from a given query for
use in dealing with the second request is less than the overhead of
reissuing the query!

This may be against REST principles which is why we've always been
careful to call SRU rest-like ;-) However, I am not convinced that this
is really is in violation of REST - in essence we are not maintaining
session state between requests - what we are doing is changing state on
the end server (i.e. asking it to store some information which can be
accessed later). If changing the state of the end service were in
violation of REST, then you could never use REST for updating a database
(for instance).

Matthew



> -----Original Message-----
> From: Farrukh Najmi [mailto:farrukh@wellfleetsoftware.com]
> Sent: 25 October 2007 02:17
> To: search-ws@lists.oasis-open.org
> Subject: [search-ws] [Issue] Server should not be asked to maintain
> client state
> 
> 
> Section 4.1 "Request Parameters" defines a resultSetTTL parameter
which
> seems to indicate that the server is expected to maintain session
state
> for the client between requests.
> Can someone please confirm this assumption. If this is true then this
> is
> a violation of REST principals. It is also quite messy to implement in
> a
> scalable manner.
> 
> I suggest we identify and remove all features requiring server to
> maintain session state for the client between requests. Thanks.
> 
> --
> Regards,
> Farrukh
> 
> Web: http://www.wellfleetsoftware.com
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in
> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]