[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: The proposed ;valuesSince-xxx option
You're right Ron. I could certainly see getting carried away with attribute options and doing things that LDAP is not really suited to do.
The driving force behind this is replication. I think replication is something that LDAP *will* have to do, and there are people involved in that effort. Any directory that does replication, at least in the way LDUP is shaping up, has to keep timestamps on each value.
I believe there's a fair amount of benefit in having access to this data, to read the timestamps and to filter on them. It would let you do things like display the members of a group in the order they were added. Applications can benefit from having a record of times for each value. It gives you some auditing information, etc.
How do other folks feel about this?
>>> Ron Ramsay <Ron.Ramsay@OpenDirectory.com.au> 09/01/99 07:10PM >>>
I take your point.
I could equally use:
commonName;returnAllValuesOfAttributeInThisServer,
or even
unknownAttribute;executeprocedure{SELECT COUNT(*) FROM basetable}.
I just feel that the idea of attaching attributes to attributes (time of
update of attribute value) id foreign to the Directory model and that
the option specified is an invitation to have the directory perform
non-directory functions. LDAP seems to encourage the view that we simply
have a repository and a protocol and we can change either to suit our
current requirements. Maybe I'm old-fashioned (sigh).
> -----Original Message-----
> From: Dave Steck [SMTP:DSTECK@novell.com]
> Sent: Thursday, September 02, 1999 2:56 AM
> To: Ron.Ramsay@opendirectory.com.au
> Cc: ietf-ldapext@netscape.com
> Subject: The proposed ;valuesSince-xxx option
>
> Regarding the proposal to retrieve only values modified since a
> certain time,
> e.g. "member;valuesSince-19980830112500Z"
>
> It was my understanding that LDAP attribute options aren't assigned
> OIDs. When the server sees the "valuesSince-", it knows how to parse
> the rest of the option. Is it necessary that all suboptions be laid
> out ahead of time and static?
>
> > -----Original Message-----
> I'm fascinated by the ;valuesSince-xxx option. Are we moving towards
> stored procedures? What are the OIDs for the attribute descriptions?
>
> 1.1.<valuesSince>.1999.8.30.11.25?
>
> I for one will be sorry to see the passing of the 'static' directory.
>
> > From: Jim Sermersheim [SMTP:JIMSE@novell.com]
> > Sent: Saturday, August 28, 1999 11:01 AM
> > To: mcs@netscape.com
> > Cc: <; <
> > Subject: Re: The 'any' attribute type
> >
> > Ok, I'll quit teasing. There are three I think, (someone else here
> is
> > defining them) They look something like this (these are only vague
> > descriptions):
> >
> > This one is used to request that a value's CSN is returned,
> prepended
> > to the value like T#S#R#s:attrvalue (see LDUP for meaning of TSRs)
> > myAttr;valueCSN
> >
> > This one is used to ask that deleted values be returned.
> > myAttr;deletedValues
> >
> > This one is used to ask that only values, update since xxx be
> > returned.
> > myAttr;valuesSince-xxx (where xxx is a GMT spec)
> >
> > I know... Why not just use controls? In the first case (valueCSN)
> it's
> > handy for LDIF and in the other two cases, it's a solution that
> > doesn't require changes/additions to the client.
> >
> > I didn't want to introduce the specific attr type options because I
> > was afraid of falling down a rathole and not addressing the 'all'
> > attrs thing.
>