Re: back-monitor problems

[Pierangelo Masarati <masarati@aero.polimi.it>]

I'm cc'ing this to -devel because it might help in continuing 
the development of the back-monitor :)

<snip>
> ...  Here's what I tried:
> 
> 
>  {
>   struct berval **timebvv = NULL;
>   struct berval *timebv = ch_malloc( sizeof( struct berval ) );
>   char timebuf[] = "1234567890Z";
> 
>   timebv->bv_len = strlen(timebuf) + 1;
>   timebv->bv_val = ch_malloc(timebv->bv_len);
> 
>   strcpy(timebv->bv_val, timebuf);
> 
>   if (ber_bvecadd( &timebvv, timebv ) < 0 ) {
>    ber_bvfree( timebv );
>   }

I think you don't need all these steps; moreover, the length
of a berval does not refer to the length of the buffer, but the 
length of the string (in case you need to use it as a string).
Finally, attr_merge is making a copy of your data anyway.

So your code could read something like:

	AttributeDescription *ad = ... ;
	char *timebuf = "...";
	struct berval bv, *bvp[ 2 ] = { &bv, NULL };
	bv.bv_val = timebuf;
	bv.bv_len = strlen( timebuf );

	if ( attr_merge( e, ad, bvp ) != LDAP_SUCCESS ) {
		/* error */
	}

Note that the currentTime attribute does not exist any longer; it has
been wiped out of the schema long time ago.
	
If you intend this as a modifyTimeStamp, you should apply it only
if the entry is modified.  To this purpose, you could provide helpers
to let sub entries developers decide whether the timestamp should
be updated or not; the same applies to the createTimeStamp.

If you intend this as the current time of the server, then you should
create a dynamic subentry of the monitor entry that contains the 
current time stap only.

See for instance the READW/WRITEW case in back-monitor/init.c
as an example of dynamic entry that once created needs to be updated 
at each call.

You may add your stuff to the 

struct monitorsubsys monitor_subsys[] 

by defining the appropriate macros, setting "MONITOR_F_NONE" for the 
children type info, and defining a "monitor_subsys_currenttime_update"
function in the update member of the structure.  According to the
style of the backend you may use the "description" attribute to hold
the value, with the "cn" attribute set to "currentTime"; this is 
because we'd prefer not to define all the attributes that were 
previously in the (single entry) monitor as independent 
"attributeType"s, but rather define different entries for each 
separate entity, holding the value in a standard "attributeType".

There's a thread about this in the -devel mailing list; see

http://www.openldap.org/lists/openldap-devel/200009/msg00031.html

and

http://www.openldap.org/lists/openldap-devel/200107/msg00065.html

Pierangelo