Mike,

You misread my intent in saying that "SRW can support implementations
which are..." rather than "SRW is ...", although I should have qualified
the statement with some words about context, but I thought that this was
implicitly obvious given the rest of the e-mail (talk about being quoted
out of context!!).

It isn't the overhead of the connection which is the issue it is the
additional overhead of keeping statefull information about the user.
E.g. in the "Ralph" example of re-issuing the query everytime (without
result set names support), the server needs top store no state
information for users. This is more efficient in terms of memory
overhead in storing any state/stored result sets, albeit less efficient
in the speed of response, although intelligent caching could be used
here. (Efficiency is always a balancing act but again I didn't think
that needed explicitly stating). This is useful when you want to support
a large number of active users under limited resources (and can assume
that all users wo'n't send in a query simultaneously).

Z39.50 doesn't really encourage this model of working whereas SRW can
support this (although can also support more traditional session based
models).

Matthew



> -----Original Message-----
> From: Z39.50 Next-Generation Initiative [mailto:[log in to unmask]] 
> On Behalf Of Mike Taylor
> Sent: Monday, August 04, 2003 10:01 AM
> To: [log in to unmask]
> Subject: Efficiency is as efficiency does (Was: Explicit 
> session termination)
> 
> I'm sorry, I can't let this go ...
> 
> > Date: Mon, 4 Aug 2003 09:35:39 +0100
> > From: "Matthew J. Dovey" <[log in to unmask]>
> >
> > Unlike Z39.50 SRW is not necessarily tied down to a simultaneous
> > user model where a connected user may be consuming resources without
> > actually doing anything. SRW works on a simultaneous request
> > model. Given that the number of active users don't all issue a query
> > simultaneously, the number of active users can be much larger that
> > the number of active requests - i.e. SRW can support implementations
> > that are more efficient than the connection based ones.
> 
> Or to say the same thing a different way --
> 
>         Unlike SRW Z39.50 is not necessarily tied down to a
>         simultaneous user model where a user needs to
>         re-connect every time he wants to actually do
>         anything.  Z39.50 works on a persistent connection
>         model. Given that a typical user issues many queries
>         in a single session, the total number of requests that
>         can be handled can be much larger than the numnber
>         TCP/IP connections that have to be forged -
>         i.e. Z39.50 can support implementations that are more
>         efficient than the non-connection based ones.
> 
> To say that a connectionless model is "more efficient" than a
> connection-based one is like saying that quadrupeds are "more
> efficient" than bipeds -- it depends entirely on what you're trying to
> do.  (And since the overhead of keeping a TCP/IP connection open is
> close to zero anyway, I think that in the great majority of scenarios
> a connection-based approach is likely to be superior.)
> 
>  _/|_    
> _______________________________________________________________
> /o ) \/  Mike Taylor  <[log in to unmask]>  
> http://www.miketaylor.org.uk
> )_v__/\  "I'd have to agree with you ...  If you were right" --
>          Robin Williams, "Awakenings"
> 
> --
> Listen to my wife's new CD of kids' music, _Child's Play_, at
>         http://www.pipedreaming.org.uk/childsplay/
> 
>