Hello Serge,
Serge Leblanc <address@hidden> writes:
> 1. Why the corollary function start_server of stop_server wasn't
> creates ? That would make the possibility from a client having
> administration rights to initialize server.
I don't understand. If you don't have a process to answer RPCs, you
can't handle a start_server() method. To start a server, you need an
external program, typically a shell script in /etc/init.d/, to start
your daemon (much like an apache web server for instance).
> 2. To be useful the function save_binary_base must be to call after
> each change of state of the structures that she save.
This was done in v0.1. I probably erased the code when migrating to the
use of full fledge RPC.
> But this
> function also lock the writing in the structures ; delegation,
> classification, position with the risk of blocking all during a
> full use.
This code was written at at time (v0.1) where the server was
multi-threaded. At that time, the locking mechanism was designed to
avoid deadlocks (that's why all bases are locked in writer mode).
The server is no longer multi-threaded so all that locking code should
go away (I've only kept it because it breaks my heart to throw away code
:).
> Would it be better to fulfill a save function for each
> structure?
Well, I don't see a real need to have per structure save function. At
least, all that code is concentrated in one function. But it might be
more useful for XML save/restore.
But to be honest, I don't like this saving in binary format. It is
unreadable and is not portable from one release to the next one. That's
why we have decided to handle saving in XML format.
signature.asc