I was thinking since some time already about mirroring between elog servers, 
and actually started already some implementation.

The problem with mirroring on the file level does not work. Assume two 
servers "serv1" and "serv2". Then assume that one message gets submitted on 
serv1 and at the same day another message gets submitted on serv2. Now you 
have on both servers a file 030726a.log, but you cannot copy this file 
simply from one server to the other, since you would overwrite the message 
submitted on the other server. Furthermore, you need file level access, 
which is maybe easy between your laptop and your desktop computer, but not 
if the two mirror servers are in different countries. Like in our 
collaboration we have three servers located in Switzerland, Italy and Japan 
(meg.psi.ch, meg.pi.infn.it, meg.icepp.s.u-tokyo.ac.jp), where we cannot 
have direct disk access.

So what I propose is the following mirror scheme:

o Each elog server may contain a list of mirror servers in the configuration 
file

o Each elog server calculates an MD5 checksum from all local messages

o Synchronization between servers can be triggered manually (by clicking 
on "Synchronize") or automatically at a given time and interval

o On Synchronization, the elogd server fetches the MD5 list from the mirror 
server and compares it with the local list

o If a message has been edited remotely but not locally, it's fetched and 
stored locally, same in the other direction

o If a message got edited on both sides since the last synchronization, the 
user is asked to resolve the conflict (keep local or keep remote message)

o If there is a new message locally, its submitted at the remote server, but 
with the same submission date/time as locally, same in the other direction

o If new messages are present on both sides, their message ID is changed so 
that it is unique, then they are copied over. If there are already replies 
to this message, their link (using the message ID) is changed accordingly

So I plan to implement this scheme in the next time. The MD5 checksum is 
already there. If anybody has comments or additional wishes concerning 
mirroring, telling them right now would be great, since I then can 
accomodate them easier during the implementation.

- Stefan

Have you tried on this forum? 

 The navigation buttons work for me but Ctrl-PgUp and Ctrl-PgDn does not in IE8 or Chrome.

However buttons and Ctrl-PgUp and Ctrl-PgDn both work in FireFox, so seems to be browser specific, I noted that in Chrome Ctrl-PgUp and Ctrl-PgDn moves through your open Tabs.

I confirm that IE8 and Chrome "eat" the Ctrl-PgUp/Dn keys, so they are not passed to ELOG, and there is nothing I can do about. 

 On this linux box, using Firefox 12, if tabs are in use, Ctrl-Pgup/Ctrl-Pgdn goes throught the tabs.  If you force tabs off, then it goes through the entries.

Bavigation buttons work fine.

  I have tried this forum, it worked fine. So, it should not be a browser. The only different I have logbook that I have been working on ELOG v2.6.5 and I have installed a new version v2.9.2. I just wonder any different data format (2.6.5 vs. 2.9.2) could have caused a problem.

The data format has nothing to do with the functionality of browsing buttons. Except if you have an empty logbook, or a logbook with just one entry, then of course going forwared and backward will not make any sense. 

I have a group includes more than one logbooks. One has about 1600 entries and another new one has 5 entries. I have tried them both. When I retested with v2.6.5, the buttons are still functional. This problem also exists on Firefox plus giving me a message "This is the first entry" "This is the last entry" when I clicked a previous button and next button respectively. I need to use v2.9.2 since it has many improvements