[be] Bibledit and web server

[Teus Benschop]

This mail is in response to the various messages written about the topic
of bibledit and the web server.

Inter-process communications

It may seem unusual why a web server is used for inter-process
communications on the same work station rather than an established
standard such as dbus. Let me give a few facts, then the reader may
judge for himself:
- "The internet says" that dbus in combination with Gtk works well, but
when threading is used as well, problems arise. Bibledit uses threading
subsystems.
- On Linux dbus was working well, apart from the standard crash caused
by the dbus system the first time bibledit started after the operating
system was rebooted. After that it worked flawlessly. gdb traced the
crash back to somewhere deep in the kernel.
- The person creating the Windows port requested the dbus requirement to
be dropped since it prevented him from making that port.
- On Macintosh the dbus system had several problems, and it always
crashed bibledit.
- Bibledit has in the past used a few other systems for inter-process
communications, but there was always some trouble when porting it to
other platforms.
- A web server works on all relevant platforms, no trouble is expected
there.
- I don't have time enough to look deep into the issues, therefore opted
for a cross-platform solution.
- Bibledit still uses dbus for communications with Xiphos and BibleTime,
but the dbus is moved into a separate helper program. If ever this
helper crashes, the main binary continues happily.

IT landscape

Looking at the IT landscape around us, we see a move towards the web and
the cloud in countries with good internet access. But we also see
countries with communications infrastructure that lags behind. There
have been requests for bibledit to become a web based translation tool.
There have been requests for bibledit to remain an off-line translation
tool with optional online syncing of changed data. Both requests are
valid depending on where the translator lives. Both requests cannot be
fulfilled at the same time. Or can they? I'm thinking of a strategy to
fulfil both requests in one package. The strategy is this:
- Bibledit will very slowly move onto the "web".
- Bibledit will test the waters on the "web" and be sure each step goes
well. Here is where the web server is used in version 4.1. It tests how
it goes and will learn from its mistakes.
- For countries with good internet infrastructure the "web" can be the
real web as we know it.
- For countries with internet access that leaves bits lacking or is not
there at all, the "web" is a local web server running on the work
station.
Here is where the local web server comes is. Once it works well locally,
it can then be made optional to move it onto the web.

Serving home pages?

It was mentioned that rather than use the web server's system-wide
document root it would better use the user's home directory. I for my
part would be very scary to think of all my data in the home directory
made accessible to the outside world. This certainly ought not to be the
default setup. Yes, it could be made optional. Think of all your private
emails getting public! What kind of security model is this?

Run-time versus compile-time dependencies.

I've read the various good arguments for making a distinction between
these, and will soon open a task on Savannah to implement this. Be
patient though, there are more tasks in the queue to be done first.

Bibledit's own tiny web server

Bibledit at present has a tiny web server. Many hours went into it to
get it work a bit, and it still has severe problems. Also looking at php
at the moment, it cannot be justified in my mind, looking at the
available time, if I were to invent the wheel again. Therefore I opted
for using standard tools, robust tools. And in the future, when a
full-blown LAMP server will be required for bibledit to run on,
including authentication, session management, multiple user accounts,
there's no way a tiny web server will do. Therefore right from the start
I thought that doing the matter well was the right thing to do. And yes,
this means using established web servers such as Apache. A whole list of
other web servers was mentioned, but I am not sure whether these do run
php and mysql. As said, however, bibledit should not dictate the web
server to use, but only put it under stress, then give feedback to the
user whether the server survived or collapsed. So, if Bibledit crashes
your tiny server in the future, be warned!

Information in source tarball

I've taken note of the various suggestions to put all required
information for packaging and compiling into the source tarball. I'll
update the information that is there.

Thanks for your input. It helps making bibledit a well-behaved package.

Teus