> > The folks who want the session id seem to be happy
> > if it's optional. Nobody seems to object to an
> > *optional* session id. There is at least one
> > implementor who claims not to support result set
> > ids (Ralph). Is it fair to say, though, that if
> > you do support result set ids then you support
> > session ids?
> No. We support resultset ids but not session ids. A resultset is an
> existing set of records. Sessions we just do not know what it is.

And you just accept that unless you assign long randomly generated names
to the result sets, that they could be misappropriated?

And that these long randomly generated names will have to be returned in
the CQL. So if I wanted to do a search using 3 different result sets, I
would have to send some ridiculously long query string. I assume that you
don't also want to have to escape the CQL in a URL, which limits you to
A-Za-z0-9 in constructing resultset names.

Say 20 characters of result set name. 60 out of 256 characters devoted to
just the names of result sets, which could be accomplished much more
easily using a session identifier and shorter result set names.

I assume that you don't expect the user to retype all of those result sets
into their query? But then you need more power in constucting the CQL than
a web browser is likely to offer, so perhaps you do?


> > So if a client sends a session id, if the server
> > supports it, he echoes it in the response and if
> > not, ignores it (so if it is not echoed the client
> > knows that the server doesn't support it). And if
> > the server doesn't support it, then it also
> > doesn't support result set ids (and signifies this
> > by not echoing it).
> >
> > Will this work?
>
> No.
>
> Lets keep it simple and just treat things as they are. What is a
> session? Especially in a web environment the context of a request
> is not the same as the session context. When u user goes back a
> few pages in his history what is his session context? His current
> page or the last page he requested? Sessions were nice when a
> user had a connection with a telnet client and only the server was
> aware of the sequence of actions.

I for one won't be implementing such a specification, as it would be a
complete waste of my time. I implemented a Google client because it was
literally 10 minutes work. If I have to write a parser for CQL, but I
can't do anything interesting with the result (due to lack of state) I'm
not going to bother starting.

Either drop CQL and go to a fully XML based query language to reduce
implementation overhead, or make it worthwhile implementing CQL by having
a non crippled protocol.

Matthew has said that this is a marketing exercise ... Fine, then make a
product worth marketing either in terms of ease of implementation or its
capabilities. But with CQL and without sessions you have neither.


> Currrently we may recognize resultsets and we may recognize
> users but I do not know what a session is. The only thing that
> looks a liitle bit like the sessions from the old days is the use of
> cookies in a browser session: cookies that are stored as long as
> you do not stop your browser. But I see that more as an alternative
> to time out the validity of a user authentication.

Most clients will not be web browsers. Cookies are a nasty hack to get
around the very fact that there is no persistent connection.
Cookies can also persist past a single invocation of a browser. They are
used for much much more than just user authentication.

Go and look at the list of soap implementations. Count how many are based
on web browsers. Yes SRU will probably be used via a web browser, but
that too is not a given. Any slightly sophisticated script that needs to
reference more than one SRU request at once will need server side code or
some ridiculous hacks such as loading the results into one pixel frames.

> BUT: when a server wants to specify some kind of property that it
> wants to have returned at a next request, lets call it <sessionid>
> and let it be sibling to <resultsetname>. BUT: for the client both
> sessionid and resultsetid and "authorisation ticket" are different
> things.
> Question: when there is a "authorisation ticket" as parameter, who
> still needs a sessionid and what for?

Where did this authorisation ticket appear from? It sounds like just
another name for session id. If you mean, on the other hand, that you do
not need session ids if you have user authentication, then I disagree
entirely and have already pointed out the various scenarios in which
sessions and user authentication are different.

Rob


--
      ,'/:. Rob Sanderson ([log in to unmask])
    ,'-/::::. http://www.o-r-g.org/~azaroth/
  ,'--/::(@)::. Special Collections and Archives, extension 3142
,'---/::::::::::. Twin Cathedrals: telnet: liverpool.o-r-g.org 7777
____/:::::::::::::. WWW: http://liverpool.o-r-g.org:8000/
I L L U M I N A T I