Re: LDAP shall speak unto LDAP + first cut at best-first searching

Tim Howes <tim@terminator.rs.itd.umich.edu> Mon, 29 November 1993 18:04 UTC

Message-Id: <199311291637.LAA26346@terminator.rs.itd.umich.edu>
To: Simon E Spero <ses@tipper.oit.unc.edu>
cc: ldap@umich.edu, osi-ds@cs.ucl.ac.uk
Subject: Re: LDAP shall speak unto LDAP + first cut at best-first searching
In-reply-to: Your message of "Mon, 29 Nov 93 11:25:58 EST." <9311291625.AA03589@tipper.oit.unc.edu>
Date: Mon, 29 Nov 93 11:37:00 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Tim Howes <tim@terminator.rs.itd.umich.edu>

> From:    Simon E Spero <ses@tipper.oit.unc.edu>
> To:      Tim Howes <tim@terminator.rs.itd.umich.edu>

> Dealing first with the request groupings; The reason I'd suggested allowing 
> requests to be grouped together is to allow a group of messages to be handled
> with the same message id. 

I agree it sounds like a reasonable thing to do.  But my question is
can't the same effect be achieved by simply marshalling multiple LDAP
requests/responses into a single udp packet for CLDAP?  If you do this,
all of the messages either arrive, or not.  There is no problem with
dropped messages, duplicate messages, etc.  At least not beyond what
you'd expect with UDP normally.  I don't see what value the outer
SEQUENCE wrapper addes over just grouping things together in the same
UDP packet.                                    -- Tim

LDAP shall speak unto LDAP + first cut at best-fi… Simon E Spero
Re: LDAP shall speak unto LDAP + first cut at bes… Tim Howes
Re: LDAP shall speak unto LDAP + first cut at bes… Simon E Spero
Re: LDAP shall speak unto LDAP + first cut at bes… Tim Howes