Yannick Lecaillez wrote:
> José Luis Tallón wrote:
[--snip--]
>
>> And the approach:
>> * filesys (direct) for init-like programs
>> * As soon as the daemon is running (libelektra checks if
>> /var/run/kdbd.sock is there), use the controller/slaves model which
>> Bárður has described before (a refinement of my original proposal). This
>> is the model used by many *high performance and secure* servers, such as
>> Apache and Postfix. Why not trust them for this? ;
>>
>>
> Could you give more details please. Don't know if i uderstood you well
> ... you mean sort of "dynamic mapping" ? Use filesys for low level stuff
> directy. Then, when daemon is here, use it ? That mean a same
> configuration could be handled by two different backend depending
> wherever daemon is launched or not. I'm not really happy with this. Why
> not simply let mappings exactly like how they have been configured ?
I took it as being static, so
system/ is _always_ mapped to filesys
system/sw is _always_ mapped to any backend
user: is _always_ mapped to any backend
(And only those mappings can exist.)
I was going to write about an alternative mapping here which would be
more friendly to large networks of machines, but I think I just realized
that static mappings maybe are not flexible enough to remain sane for
both small and large configurations. (The mapping I wanted would also
store machine configurations in a central location, but mapped so that
the configurations were still separate from each other.)
Can I change my mind? ;)
I think we really want dynamic or at the very least
arbitrary-but-only-read-at-startup mappings.
[--snip--]
> The fact is i would have maximum flexibility and KISS (Keep It Simple,
> Stupid) as possible. Creating dynamicly pipe, process, agent will simply
> add complexity without adding (IMHO) enought good value.
Pipes wouldn't _have_ to be created dynamically. With named pipes they
could be precreated, and any particular user's daemon could be started
by the user themselves -- though probably by libelektra starting it for
them.
As I think I mentioned, the setup I had in mind doesn't actually require
separate processes -- it simply requires being able to do non-blocking
I/O (which the daemon needs to do anyway) and to direct requests to
multiple different backends. However, if you want the best possible
security you _have_ to separate the "user daemons" from the "system"
daemon (and the root:root daemon which directs requests to the
appropriate daemon).
It _is_ somewhat complicated, but frankly, I would just start by
creating a prototype/proof of concept in Python, Ruby or some other
high-level language... and only after that has show that the concept is
workable worry about implementing it in a low-level language like C.
(C++ might also be considered as the "final" language... Boost.Asio is
set to make non-blocking I/O very easy and Boost.Statechart makes
implementing server state very easy indeed.)
>
> Adding caching stuff to kdbd is something i'm thinking too. Its "easy"
> to do for local backends (understand stored localy on filesystem) but
> not as easy for remote backends : cache system have to be aware about
> each modification done and these modifications could have be done not by
> you (your instance of kdbd).
Well, you can always relax the consistency requirements slightly if
you're willing to live with programs possibly using slightly outdated
configuration information (usually not that big a deal unless you do
modifications on both "sides").
> Afaik, LDAP allow you to monitor some
> branch/objectClass for modification. But for SQL that's another story ...
> So perhaps caching stuff would probably have to be done in the real
> backends themself rather than into kdbd.
>
I think caching is best left to the LDAPs of the world. I'm sure there
is a *lot* of expertise and work that has been poured into making LDAP
caching work reasonably and reliably, and I would be surprised if a
relatively small project like Elektra could come up with something
*significantly* better to justify the effort... Anyway, the door on that
is still open once the basic stuff is in place.
--
Bardur Arantsson
<[EMAIL PROTECTED]>
- Who says staring isn't exciting?
World Staring Championship Commentator, 'Big Train'
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Registry-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/registry-list
