Hi
    Christian-

   Yes I get it that Genode already has a fairly nice configuration process utilizing XML....   and you might be on the right track when you take my comment about the use of a potentially augmented text / XML structure editor for easier display / editing of these XML config files.. 
... but I have to confess I'm not all so much of a fan of XML in terms of it's direct readability....  maybe it's a good middle ground... but in all honesty, I would prefer a Json like syntax over XML.... or more exactly... When people suggest that every thing should be encoded as an XML file... I tend to concur with those in t crowed who just role there eyes... 
   That is: there does seem potential for the use of domain specific languages...   i.e. XML does not always seem to be the best answer...
   I'm just suggesting that the complexity jump to GUI based config may not be the best trade-off in the context of smaller embedded Genode systems..

    Hope this helps.
     -Peter     

On Wed, Dec 23, 2015 at 3:21 AM, Christian Helmuth <christian.helmuth@...1...> wrote:
Hello Peter,

thanks for your sharing your thoughts. Let me please comment on your
remarks about configuration mechanisms for Genode...

On Tue, Dec 22, 2015 at 02:08:17PM -0800, Peter Lindener wrote:
> *   Norman wrote: " *Supplementing Genode with user-friendly means to
> configure...**Right now,  **I use Vim as configuration front end, which is
> cool...*"
>     My thought: One can certainly get a lot of configuration usability out
> of a basic, potentially colored, 2D ASCII text document. Not to mention how
> much lighter and more portable the (potentially remote) terminal display
> can be.
>    So while GUI tool kits are great for some things, I'd like it if little
> headless nodes running Genode (Snickerdoodle <http://krtkl.com/>) would be
> just as easy to re/configure.   Thus I vote that Genode's next generation
> of [ASCII] configuration files are both very easy to read, in addition to
> edit with a (potentially augmented) terminal emulation program...   i.e.
> lets not prematurely jump on the GUI bandwagon, before Genode achieves a
> similar ease of configuration using a significantly lighter level of
> display / keyboard interaction...

I suggest you have a look at our release documentation for Genode
15.11 [1]. There we explain how Genode components are configured
individually and assembled to meet functional and security
requirements of specific use-case scenario. Furthermore, the basis for
our configuration is XML syntax since the beginning (see [2] and [3]).
For thorough documentation of the concept of component configuration
you may have a look into the Genode Foundations book Chapter 4.6.

>From my point of view, this sheds some light on Norman's comment about
using Vim to configure Genode, which should be taken literally: Any
aspect of the system can be configured by editing XML config files and
additionally our reporting mechanism is using the XML syntax too. I
admit that I'm not striving for mere ASCII support but envision to use
UTF-8 in the future for XML attribute values and node content, but
that's a small detail. The mentioned appealing GUI "agents" are
nothing but alternative front ends, but on the other hand important to
get less technical users on board.

[1] http://genode.org/documentation/release-notes/15.11#Uniform_run-time_configuration_concept
[2] http://genode.org/documentation/release-notes/12.05#System_reconfiguration_at_runtime
[3] http://genode.org/documentation/developer-resources/init

>     given the goal stated above, why not at the same time provide a very
> nice set of terminal interaction API's within the Genode framework, that
> one can count on as a lower level system resource, such that other light
> weight apps that run on Genode can also count that this terminal
> interaction API might be made available as shared resource.

If I'm not mistaking this comment entirely, I'd like to refer you to
our neat APIs for XML handling, which are the Xml_node and the
Xml_generator. We apply these tools throughout the Genode source if
configurations and reports are processed. The most prominent component
using them is Init, but also the windows manager components, our
platform driver, device drivers, VirtualBox, and many more.

So, what's currently missing for your use case may be a terminal-based
"agent" for dynamic configuration if Vim is unsuitable. I personally
see no need to add ncurses-like tools tailored for configuration, but
your opinion may differ.

Regards
--
Christian Helmuth
Genode Labs

http://www.genode-labs.com/ · http://genode.org/
https://twitter.com/GenodeLabs · /ˈdʒiː.nəʊd/

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

------------------------------------------------------------------------------
_______________________________________________
genode-main mailing list
genode-main@...12...ceforge.net
https://lists.sourceforge.net/lists/listinfo/genode-main