 |
 |
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 so complex? --Ray ----- 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! Matthew