Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 20 Nov 2015 15:19:05 +0000
From:      Vsevolod Stakhov <vsevolod@highsecure.ru>
To:        Dan Partelly <dan_partelly@rdsor.ro>, freebsd-hackers@freebsd.org
Subject:   Re: libUCL / UCL as FreeBSD config question
Message-ID:  <564F39E9.3030303@highsecure.ru>
In-Reply-To: <5B598F72-C5DD-48FD-866D-F90E117D646E@rdsor.ro>
References:  <5B598F72-C5DD-48FD-866D-F90E117D646E@rdsor.ro>

next in thread | previous in thread | raw e-mail | index | archive | help
On 18/11/2015 07:55, Dan Partelly wrote:
> Hi all,
> 
> 
> is LibUCL able to read in memory a UCL key-value database , modify it in various ways :
> 
> 1. Add a new key-value pair
> 2. Modify the value of a value
> 
> and serialise the modified database back to disk ?
> 
> Or it is designed only a one way / read-only configuration mechanism ? 
> 
> The reason Im asking is this: 
> 
> if UCL becomes the new config mechanism of FreeBSD, does it brings any other advantage 
> than an easy to read and humanly write format ? Would this library/language be usable in 
> any other way in system configuration — apart from autoexec.bat way  —> use command line tool
>  to read key-vaule , filter it with some tool back to plain **text** and feed it to a command line utility
>  from FreeBSD base ? 
> 
> Let’s say one writes a network config daemon to handle network configuration, and expose network 
> configuration (like interface management, route management, DHCP bindings and so on), which 
> exposes all this functionality to the rest of the system through IPC. Now, let’s say , a simple client
> modifies the IP address of a certain interface, or host name or whatever, and in process modifying the
> corresponding  key-value in memory, in addition to sending the IOCTL to change ip address for the interface 
> to the kernel.
> 
> Is lib UCL able to serialise this change back to the file which backups up the database  ? If it is , all is dandy, 
> If it is not, is is this feature easy to implement in libUCL , without being a hack, or libUCL design was  read only 
> from start, thing  which  would make serialisation hard to implement cleanly ?


UCL supports serialization to native UCL ('config'), JSON, compacted
JSON (with no lint) and YAML[1]. So far, there is also support of
emitting msgpack binary format for UCL objects.

>From the API perspective, libucl allows custom emitters[2], for example
to output to some C string or dynamically growing string, or stdio file.
There is also streamlined API that allows emitting of incomplete UCL
objects (e.g. those that are too large to fit in memory).

The only unimplemented feature is the format preserving emitting. We
have discussed it during the recent BSDCan, but I had no time to
implement any of the discussed approaches unfortunately.

[1]: https://github.com/vstakhov/libucl/#emitter
[2]:
https://github.com/vstakhov/libucl/blob/master/doc/api.md#emitting-functions-1

-- 
Vsevolod Stakhov



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?564F39E9.3030303>