Starting from version 2.2.5 on, an new directory scheme has been 
implemented. The idea is to separate the config file from the theme/icon 
and the logbook directories. This can now be achieved by specifying the 
configuration file via the "-c" flag and the directories with the "-d" flag 
for the logbook root and the "resource directory" with the "-s" flag.

Alternatively, the resouce and logbook directories can be specified in the 
configuration file with

Resource dir = ...
Logbook dir = ...

The old "Data dir" statement is still possible but deprecated. Instead, the 
statement "Subdir = ..." should be used which is taken relative to 
the "Logbook dir". If no "Subdir" is given, the logbook name itself is used 
as the subdir. For this demo logbook I use now:

[global]
...
Resource dir = /usr/local/elogdemo
Logbook dir = /usr/local/elogdemo/logbooks

and no "Data dir" statements any more. The logbooks "Linux", "Database" 
and "Forum" are then located at

/usr/local/elogdemo/logbooks/Linux
/usr/local/elogdemo/logbooks/Database
/usr/local/elogdemo/logbooks/Forum

respectively. The help, theme and icon files are located at their old 
position ("themes" is automatically added to the "resource dir" as it was 
before).

From Version 2.2.5 on, the configuration file entries

User = ...
Group = ...

have been changed to

Usr = ...
Grp = ...

in order not to conflict with the new "Group = ..." option which is used by 
hierarchical logbooks.

propose to put 
[Submit] [Back] [Submit & Notify] button on top/bottom

new parameter 'shell option' 

[test]
...
Attributes = NotifyMode, Param1....Param10, Adresse, Subject, ...
Options NotifyMode = mail, SMS, Fax, printer...

; this command will invoque a shell command  
; example       
ShellCommand = <my shell command> parameters ...

like in WINDOWS 2000
ShellCommand = START.EXE notify.bat $NotifyMode $Param1, $Param2, $Param3
; in this case no necessity to modify the C source
; in windows I suggest the start.exe with a exit command
; so no necessary to wait the return code from the shell

Can you consider implementing the following additions to the functionality

1) Subt on edit <attribute> = xyz 

This would be fantastic for implementing version control so you can see who 
has edited a posted or a db entry.

2) Have a SORT fieldname flag so you can decide which column to sort things 
by on a display listing in conjunction to the display flags, it current 
defaults to the # column and I find i am directly linking to a sorted 
display

3) Have the elogd.conf track actual log entries people have changed 
detailing date and time etc.

4) Ability to export contents of the log books to files on disk for backup 
purposes as all data is contained within a single log file which causes 
problem for command line searches.


Many thanks 

> Can you consider implementing the following additions to the functionality
> 
> 1) Subt on edit <attribute> = xyz 
> 
> This would be fantastic for implementing version control so you can see 
who 
> has edited a posted or a db entry.

Can you give me an example of how you would use that?
 
> 2) Have a SORT fieldname flag so you can decide which column to sort 
things 
> by on a display listing in conjunction to the display flags, it current 
> defaults to the # column and I find i am directly linking to a sorted 
> display

Sorting is not done by the "#" column but by the sequence when messages have 
been entered. You can sort the table differently by clicking on the table 
titles (twice for reverse sort). To sort by default on a column, for example 
sort by the author, you can add

Start page = ?sort=author

into elogd.cfg which does the job.

> 3) Have the elogd.conf track actual log entries people have changed 
> detailing date and time etc.

Revision management is not forseen by the structure of the ELOG database. 
What you can do is if you edit a message you check "Resubmit as new entry", 
then you keep a copy of the old version. 

> 4) Ability to export contents of the log books to files on disk for backup 
> purposes as all data is contained within a single log file which causes 
> problem for command line searches.

Well, you have already all log book files on disk in a simple format:

YYMMDDa.log

(Year/Month/Day) which you can easily backup. By a mask like 02*a.log you 
can backup all data from 2002 and so on. The idea of having separate log 
files for each day is to have this possibility to simply backup various date 
intervals. 

What kind of command line searches are you interested in?

- Stefan

I noticed the site has been updated as far as the documentation for 2.3.1, 
however the latest version in the downloads section is 2.3.0, any other 
places where I can get 2.3.1

Cheers

> I noticed the site has been updated as far as the documentation for 2.3.1, 
> however the latest version in the downloads section is 2.3.0, any other 
> places where I can get 2.3.1
> 
> Cheers

Patience, patience! 2.3.1 is currently kind of in "beta" version, but will be 
released this week. Not that you can always get the latest snapshot from the 
CVS tree at

http://midas.psi.ch/cgi-bin/cvsweb/elog/src/elogd.c

- Stefan

To obtain the newest source code of ELOG, go to the CVS repository at

http://midas.psi.ch/cgi-bin/cvsweb/elog/src

It contains usually the newest bug fixes, which will show up in the next 
realease. On the other hand it can also contain some new features, which 
are not yet fully tested, so care should be taken when using it. The 
revision comments usually explain what is new in that revision.