RE: Proposal: make init optional

I'll speak up for Bob's proposal, for exactly the reason he gives in his
message.

At the last ZIG meeting, I believe we made significant progress in agreeing
that we need to separate the Z39.50 semantics from the current BER based
syntax.  That means that we are free to consider Z39.50 messages encoded in
other syntaxes.  When I start crafting some HTTP based, semantically
equivalent, searches, I'm not going to want to embed them inside an Init
request.

So, if we hope to use the experience and semantics of the Z39.50 community,
we better be prepared for some changes.  I strongly encourage dropping Init
as a mandatory operation.

If the existing implementations think that it should be kept, then it can be
added to the profile for Z39.50 over raw TCP/IP.

The whole state table issue needs to be seriously reconsidered, in light of
the new environments that Z39.50 will be moving into.

Ralph

> -----Original Message-----
> From: Robert Waldstein [mailto:wald@library.ho.lucent.com]
> Sent: Tuesday, January 09, 2001 12:50 PM
> To: Ray Denenberg
> Cc: ZIG List (at W3C)
> Subject: Re: Proposal: make init optional
> 
> 
> 
> > Sorry but I just can't go along with Bob's logic flow here. 
> Let's agree that
> > doing an Init is not always useful, and can sometimes be a 
> nuisance.  That's one
> > of the primary reasons that we invented encapsulation! To 
> now argue that
> > encapsulation is too hard so let's make Init optional seems 
> counterproductive to
> > me.
> > 
> > Encapsulation in it's full generality may be hard but you 
> could implement just
> > enough of encapsulation to cover this Init problem, and 
> certainly that would be
> > easier than all the problems associated with the proposed 
> change to make Init
> > optional, wouldn't it?
> 
> I was proposing this in the mode of making z39.50 more internet-like
> and fast implemented; and I keep hearing popping up the need
> for a search/retrieval in one round trip.
> 
>   I am totally willing to drop it; and leave the idea hanging 
> around for when
> this issue next arises.  Yes - encapsulation does everything; 
> but it would
> always be a non-trivial addon to a working implementation: 
> probably both
> for a server or client implmentation.  If the "goal" is 
> something that will
> compete with typing an nlsearch/alltheweb/altavista style 
> search string
> at a telnet prompt; encapsulation isn't the best answer to give such
> an implementator.
>   But consider it proposed and dropped - wanted the idea 
> hanging around though,
>      bob
> 
> -- 
> Robert K. Waldstein                Email: wald@lucent.com
> Bell Laboratories, Room 3D-591     Phone: (908) 582-6171
> 600 Mountain Avenue
> Murray Hill, New Jersey  07974
>

Received on Tuesday, 9 January 2001 13:37:52 UTC