MobileRead Forums - View Single Post

knc1 · 08-08-2013, 09:59 AM

Ah, gee, I didn't write up "why", did I, my bad.

Take the case of two (or more) independently developed KUAL button applications that are inter-dependent.

A good (and currently broken) example:
The USBnetworking and the KUAL firewall (in which the user may switch between Amazon's firewall and our firewall).

When making iptables changes, the KUAL firewall needs knowledge of the current service settings made by the USBnetworking - without poking into its configuration settings or trying to parse the system state.

When making service changes, the USBnetworking needs to know which firewall is in effect and other 'private to the firewall' configuration information.

Hence, the KUAL registry database.
Which can provide an agreed upon API for these two add-ins to discover dynamic settings of the other.

USBnetworking, SSH over Wifi button: Which firewall am I putting a hole in?

Code:

kdb get $KDB_ROOT/system/kual/firewall/mode

KUAL firewall, switch firewalls: Is ssh over wifi currently allowed by USBnetwork?

Code:

kdb get $KDB_ROOT/system/kual/usbnet/ssh.wifi

And a zillion other combinations of things.

Each button action just does a 'kdb set ...' in its own part of the registry tree to publish its part of the current system state.

And with our own build, we can enable the dbus communications.

I really wasn't going to build this just to make it easier to mess with Amazon's configuration set-up.

08-08-2013, 09:59 AM	#2
knc1 Going Viral Posts: 17,212 Karma: 18210809 Join Date: Feb 2012 Location: Central Texas Device: No K1, PW2, KV, KOA	Ah, gee, I didn't write up "why", did I, my bad. Take the case of two (or more) independently developed KUAL button applications that are inter-dependent. A good (and currently broken) example: The USBnetworking and the KUAL firewall (in which the user may switch between Amazon's firewall and our firewall). When making iptables changes, the KUAL firewall needs knowledge of the current service settings made by the USBnetworking - without poking into its configuration settings or trying to parse the system state. When making service changes, the USBnetworking needs to know which firewall is in effect and other 'private to the firewall' configuration information. Hence, the KUAL registry database. Which can provide an agreed upon API for these two add-ins to discover dynamic settings of the other. USBnetworking, SSH over Wifi button: Which firewall am I putting a hole in? Code: kdb get $KDB_ROOT/system/kual/firewall/mode KUAL firewall, switch firewalls: Is ssh over wifi currently allowed by USBnetwork? Code: kdb get $KDB_ROOT/system/kual/usbnet/ssh.wifi And a zillion other combinations of things. Each button action just does a 'kdb set ...' in its own part of the registry tree to publish its part of the current system state. And with our own build, we can enable the dbus communications. I really wasn't going to build this just to make it easier to mess with Amazon's configuration set-up.