Some short pointers to show I am listening:
...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
This is why I hated Z39.50 architecture and I for now love almost everything
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
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.
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.
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.