<blockquote style="border-style: none none none solid; border-color: -moz-use-text-color -moz-use-text-color -moz-use-text-color rgb(204, 204, 204); border-width: medium medium medium 1px; padding: 0cm 0cm 0cm 0.05cm; margin-left: 0cm; margin-right: 0cm; margin-bottom: 0cm;">
> One of possible solutions is to make system dependent
dictionary<br>> mapping event to some script and use it like
in such pseudocode:<br>><br>> runner =
RunnersFactory.createRunner(EVENT_NAME)<br> Why not just replace
the shell script with a version that uses tools available on FreeBSD?</blockquote>
<p>It's to make more abstract from event handler implementation. In
the simpliest case (to keep all in scripts, but give opportunity to
extend event handler types in future) it's possible to make
dictionary, used by this factory with EVENT_NAME =>
some_os_system/event_name.sh. for Linux it will be
linux/event_name.sh, for FreeBSD freebsd/event_name.sh and etc. So
you may still work with shell scripts, but it is hided from higher
level of code. If you add in runtime want to change script, then you
just modify dictionary (via control socket or somehow else) and newly
created handlers will automatically use new script, without changing
of core source code.<br><br>> I want to keep netconf as simple as
possible and, in true Unix<br>> fashion, it should let other
programmes what they do.</p>
<p>Ok, I've understood your point.<br><br></p>
<blockquote style="border-style: none none none solid; border-color: -moz-use-text-color -moz-use-text-color -moz-use-text-color rgb(204, 204, 204); border-width: medium medium medium 1px; padding: 0cm 0cm 0cm 0.05cm; margin-left: 0cm; margin-right: 0cm; margin-bottom: 0cm;">
> = 4 =<br>> May be policy and security related
problems. IMHO, syntax like<br>> squid acls is good enough.
E.g.<br><br>The policy also needs to be able to encode flow,
like what is to<br> happen when DHCP fails to get a lease.</blockquote>
<p>by policy here, I've meant security policy.<br><br>>> = 5
=<br>> This is more or less what I want, yes: the policy tells you
which<br>> approach to take when the previous one failed.
Approaches are<br>> implemented by modules.</p>
<p>What do you think about some kind of semi-automatically choosen
flow?</p>
<p>Every module (event handler) has definition (category, e.g. "DHCP client" and
priority). Definition may:</p>
<ol><li><p>be given in "flow policy" file</p>
</li><li><p>category taken from module via call to some known function,
priorities are taken from flow policy file.</p>
</li></ol>
<p style="margin-bottom: 0cm;">There may be dispatcher, which has info
about all defined categories checks result of event handling and
chooses from available modules, depending on needed category and
priorities of modules.</p>
<p style="margin-bottom: 0cm;"><br>>> = 7 =<br>> ACPI
handlers should talk to netconf vie the control socket; they're<br>>
not part of netconf, and netconf should not even know about ACPI.<br>I'm
not sure, if netconf has now event kind of "save current state".
As netconf is aimed to configure network, ACPI handling scripts must
only ask to save interfaces state, renew state after powerstate
change and etc. I've meant such kinds of events as it a little bit
differs [or may differ] from initial configuration.</p>
<p style="margin-bottom: 0cm;"><br>> Thanks for your interest.
Sorry if my answers are a bit short, I am<br>> too tired...</p>
<p style="margin-bottom: 0cm;">Thanks for comments.</p><br>
---<br>Best regards,<br>Alexey<br>