Windows-like registry for Linux?

[Jerry Feldman]

On Tuesday 14 February 2006 3:50 pm, Steven W. Orr wrote:
>
> Right. socketpair is not the answer. It's just part of a proper
> architectural approach. What I'm suggesting is that a single server gets
> designed to access the data, maybe even using mmap or whatever else you
> want to use. Then that server would accept connections from arbitrary
> clients. The clients connect using the socketpair trick and then a
> mini-language would be used to tell the server what it is that the client
> wants. That way access is confined to one process (the server), runtime
> overhead is confined to one process (the server), and the client ends up
> stoopider and simpler.
I would agree here as long as there is an approach in the client to do 
something if the server is not running. 
It really comes down to what data needs to be stored, how and where. The 
in-memory approach is generally much faster than the database approach. 

The advantage of a single server approach is that only it needs to know the 
storage method, so if you start with a simple linear search of some shared 
data (whether it is multiple threads sharing data within a process, or 
multiple processes sharing data allocated by the server), when you want to 
change from a linear to a better search algorithm, only the server code 
needs to change. The client needs only to know how to communicate with the 
server, and that depends a bit on what IPC method that is desired. 
The problem I have with socketpair() is that it assumes a parent-child 
relationship. In the case Michael described, my assumption is that the 
clients could be independent of eachother. But the use of sockets is 
probably a decent approach.

-- 
Jerry Feldman <gaf at blu.org>
Boston Linux and Unix user group
http://www.blu.org PGP key id:C5061EA9
PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9