LDAP schema

[Francis J. Lacoste]

On mer, 2003-04-09 at 06:53, Lire wrote:
> hi all:
> 
> i send the LDAP schema that we use for the LDAP superservice. 
> i have several question about this:
> 
>     first: i use the value string for several fields. Someone like client
>     could be hostname. is it rigth? must i change the type of this
>     field? 

Yes, it might be useful to use hostname for the client. One things that
we want to do is to provide the possibility of resolving IP addresses
to hostname for hostname and ip field types. But for now, there is no
real differences between the hostname and string types.


>     Moreover others fields like operation have defined values
>     like enumerated types in other lenguajes. how i can implement this
>     type here?

Unfortunately, there is no enum-lie type available for now. It may
change in the future, but for now we use the string type and document
the possible values for the field. 

> 
>     second: i use default values because some messages in the log 
>     havent all field full. i know that when lire dont find some fileds
>     in the message put "LIRE NOT AVAIL" in the output of parser. do
>     you think that i must use the LIRE NOT AVAIL or default values?
> 

In current CVS, the "default" attribute for fields isn't used anymore
and the meaning of LIRE_NOTAVAIL changed.

In Lire 1.2.1, LIRE_NOTAVAIL was used for the DLF converter didn't
support that field at all. For example, in the www schema there are many
fields that aren't available when in the common log format (like
useragent or referer). The default value was used when the field was
supported by the converter, but there was no value present in the log
file.

No this behavior wasn't really optimal for it wasn't possible to
distinguish a record which got the default value and one where the value
was present in the log but equal to the default values. Plus, most of
the time, the default values was '-' which doesn't mean a thing.

The new semantics are the following:

LIRE_NOTAVAIL is now equivalent of a NULL value. It means that no data
was present in the log file for that field. It also means that some
records can have a NULL value for a field while others have a real
value. NULL values are also skipped from the computation. (like in SQL
and in most statistical algorithms). 

Default values aren't used anymore in schemas. The DLF converter might
provide a value if one can be inferred from the absence in the log, but
this is specific of the DLF converter, not the schema as a whole. 

For example, in your case, it would be logical for your DLF converter to
set the 'operation' field to 'NOP' when the record wasn't an operation
*and* you want to be able to report on that values.

A way to think about that, is to ask yourself if I did a records by
operation report, would I want an entry to show NOP X or not. In the
case you want to see that entry, you set a default value in your
converter, otherwise you don't and you'll get the new NULL behavior.

Hope this makes it a little clearer.


Francis J. Lacoste

-- 
Francis J. Lacoste              . .           http://www.logreport.org
/^LogReport$/               . .               flacoste at logreport.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.logreport.org/pipermail/development/attachments/20030411/164434ce/attachment.bin