> Ah, you test me!  Perhaps I will attempt to dig into this but I may have to leave the
> integration up to you, Stefan.  Seems that there would be two roads to go:
> 1> Move away from standalone and start to rely on Apache
> 2> Continue with the standalone theme and build in LDAP authentication (which could
> also give you groups functions as well). 
> 
> I think I would opt for <2>

<1> would only make sense if the functionality could be completely implemented inside
Apache, without (much) modification of elog. Otherwise I agree that <2> would be more
following the general lines of elog. I was considering to implement PAM (pluggable
authorization module) support into elog, which is quite easy to implement and gives you
to power of having LDAP, Kerberos, Unix username, Windows NT Domain and much more. But
that would them be restricted to elog running under Linux (and Solaris I guess), since
I'm not aware of a PAM implementation under Windows.

Implementing LDAP directly into elog gives me the problem that we don't use LDAP
authentication at our institute (it's Kerberos in fact). So I would have to set up my own
LDAP server for testing, plus we at our institute don't have a direct benefit from that,
which would make it hard for me to justify to spend time on.

> > Ah, you test me!  Perhaps I will attempt to dig into this but I may have to leave the
> > integration up to you, Stefan.  Seems that there would be two roads to go:
> > 1> Move away from standalone and start to rely on Apache
> > 2> Continue with the standalone theme and build in LDAP authentication (which could
> > also give you groups functions as well). 
> > 
> > I think I would opt for <2>
> 
> <1> would only make sense if the functionality could be completely implemented inside
> Apache, without (much) modification of elog. Otherwise I agree that <2> would be more
> following the general lines of elog. I was considering to implement PAM (pluggable
> authorization module) support into elog, which is quite easy to implement and gives you
> to power of having LDAP, Kerberos, Unix username, Windows NT Domain and much more. But
> that would them be restricted to elog running under Linux (and Solaris I guess), since
> I'm not aware of a PAM implementation under Windows.
> 
> Implementing LDAP directly into elog gives me the problem that we don't use LDAP
> authentication at our institute (it's Kerberos in fact). So I would have to set up my own
> LDAP server for testing, plus we at our institute don't have a direct benefit from that,
> which would make it hard for me to justify to spend time on.


Yes, PAM is highly dependent upon Unix and PAM would work under Solaris just fine.  Your
problem lies with Windows - hence my LDAP suggestion.

And LDAP isn't an easy thing to setup, but I bet there is a quick and dirty "test" bench that
could be rigged using OpenLDAP.  Like I indicated, I'll see what I can dig up on this front -
but I make no promises wrt delivery time!

Thanks to Recai Oktas, who encourage me to complete the Bulgarian
translation for the Debian elog package, the Bulgarian translation is
completed and attached.

Thanks, the file will be contained in the next release.

The <pubDate> item doesn't appear to be a valid RFC-822 date.  Causes some
aggregators to fail when parsing.

The error is shown by Feedvalidator:
http://www.feedvalidator.org/check.cgi?url=http%3A%2F%2Fmidas.psi.ch%2Felogs%2FForum%2Felog.rdf

> I implemented experimentally RSS feeds into Elog. Before releasing this new
> addition, I would like to collect some experience with it. This forum now
> supports RSS feeds, for which you can subscribe with a RSS feed reader like
> Mozilla Firefox. Please give it a try and send me any feedback.
> 
> For an introduction to RSS feeds, please see 
> 
> http://www.webreference.com/authoring/languages/xml/rss/intro/
> 
> To subscribe to a logbook, enter following URL into your RSS reader:
> 
> http://<your-elog-host.domain>/<logbook>/elog.rdf
> 
> From the newest Mozilla Firefox browser, you can also click on the RSS box at
> the lower right corner of the browser (see attachment).

> The <pubDate> item doesn't appear to be a valid RFC-822 date.  Causes some
> aggregators to fail when parsing.

I fixed that, now it passes the Feedvalidator. New version is under CVS.

I have a logbook with an attribute that has a number of fixed values. I 
use MOptions to prevent typos when entering and allow multiple "keywords".
When searching the users can only search on one keyword.
Is there any way to search on multiple values (AAA|BBB|CCC)? If I do not 
use MOption, they can do this, but the users entering logs may mistype the 
keywords.

If an attribute uses MOptions and is also extendable, clicking "Add 
<attribute name>" and entering a value adds the value to the MOptions, but 
does not put the value into the log entry. The log record has that 
attribute blank.
You have to go back into the record and edit it to put the new value in.