Good point about keeping "1.0" simple and let the complexity creep in later.
However, on the point we're debating now, it seems to me that what we decide
we're going to be stuck with (or at least it's going to be real hard to
change) so we better get it right. That is, if the server assigns result set
ids, it's going to be very akward to change that to the client assigning
them in a future version.
And further, I for one find the argument for at least a result-set-id
qualifier (which could function as a session id) very persuasive.
Is having the client assign the id and the server assign a qualifier really
----- Original Message -----
From: "Matthew Dovey" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Saturday, June 15, 2002 6:36 AM
Subject: Motivation: Occam's Razor
Just to justify why I keep playing Devil's advocate to new suggestions
I still feel that there is an awful lot in Z39.50 which just doesn't get
used. I know Rob would argue that is what makes Z39.50 powerful (and I
know Rob is one of the few who actually uses that stuff), but in general
we have a lot of baggage in Z39.50 which is there due to it being a
clever idea rather than because people implemented it (a few cases
someone said they needed it but never actually implemented it).
My personal opinion is we should keep SRW/SRU fairly simple and not
introduce anything because we can but because it is really needed (real
world case and usage scenarios rather than hypothetical).
At least in version 1.0 - it seems to be that the successful protocols
are ones which were extremely simple in the first release (HTTP, HTML
etc.) in many ways naively so. But they only started to add the
complexity after they'd hit mainstream acceptance. If you hit the world
with an all singing all dancing protocol from day one, its complexity
puts people off.
As I've said before, cynical though it may be, I see ZiNG as a marketing
exercise as much as anything else!