Some short pointers to show I am listening:
Matthew wrote:
...Also since ZNG is a sessionless protocol, the concept of concurrent
users no longer applies. In terms of resource (CPU/memory) etc. management
the issue is now how many result sets can be maintained (cached) on the
server....
Rob replies:
This is why I hated Z39.50 architecture and I for now love almost everything
of ZNG.
The advantage of an optional!! session ID is that a server can easily keep
users apart. It would make some implementations simpler. "Caching" access
attributes do not work that well in case of limited time access or limited
searches access.
In practice the server would keep some client attributes with the session ID
to make spoofing hard.
For hit and run type queries, or low volume applications, like we plan for
now, the difference is maybe mute, but I do not like:
resultSetName = "SomeSessionId%SomeSetNumber" trickery.
Ralph wrote:
Since my server does no smart caching, my client will be kind enough to use
the resultSetName when fetching more records from a result set. I hope other
clients will be as kind.
Rob replies:
Yes my server too. In a volatile system "static" sets are an illusion but in
practice resultSetName both helps the implementor and the user. I think it
is worth its own field.
Rob Koopman
PICA
|