List of topics that I have been or am working on

[Ingo Albrecht]

Just for the sake of collaboration, here is a very lose and high-level
list of things that I have been working on at some point or am currently
pursuing.

Being on this list does not mean that something is strictly important to
me, just that I have experimented with it or thought about it. My
interest in command-line libraries goes back a long time, which is why
this list is so long and broad.

Topics under "immediate" and "working on submission" are of actual
practical use to me and will be used in personal production. As an
embedded/system developer I am also considering uses for clish in some
products that I am working on.


Immediate topics:
* Get my python plugin working and possibly mainline
* Integrate clish changes that are required for nice python support
* Flush my backlog of minor fixes and changes (almost done)

Working on submission:
* View actions
* Patch exists for one action, should be many
* Actions executed when view entered
* Action failure means view change fails
* Executed in load order
* Can be used to spread python imports over modules
* More modular than setting up state in a viewid command

Research patches and enhancements:
* Prefixed alias commands (done, not needed)
* Prefixed wrapper commands (discussion, old code)
* Pager integration
* Some router CLIs have nice pager integration
* UNIX-approach: use an external pager program with a pipe
* Use a pager that does not engage if output is shorter than terminal
* Use a pager that is easy to quit by scrolling against the EOF
* Use a pager that is secure (no command execution)
* Support PAGER and/or CLISH_PAGER environment variables
* Experimental sqlite3 plugin
* Uses param expansion for safe SQL templating
* Intent is to use it for something like libpam_sqlite/libnss_sqlite
* Works okay
* Displaying data nicely requires several "renderers"
* Introduce simple low-weight logging library
* clish is big enough to profit from one
* could integrate with machine-interface
* field-oriented debug logging without DEBUG
* developer-oriented debug logging with DEBUG
* my sqlite plugin uses this as an experiment
* generalize error decoding (errno, xml...)
* compile-time removable

Possible interest:
* Generalize forking
* Lua plugin always forks
* Python plugin never forks
* There are usecases for all possibilities
* Forking is a cheap way of keeping the environment clean
* Background logging support
* Requires a partial event loop
* Have one more more background processes
* Output only complete lines
* Hide prompt before output
* Re-display prompt editor after output
* Enhance lua plugin
* Support for explicit params/var expansion
* Maybe enhance to same degree as python plugin
* I know OpenWRT people who might want to use it
* Make konf fully optional
* There are usecases where it is the wrong tool
* I have some interest in NETCONF configuration models
* Improve signal handling
* Its problematic
* We don't want to get into job control
* Generalize child process handling
* Should be callback-based
* All but required by background logger
* Could be from event loop library
* Replace plugin text with actions (idea)
* Interpreter plugins might want features from actions
* Config action currently isn't locked or interrupted
* Config actions do not get var expansion (_pid, ...)

[Ingo Albrecht]

Other items with patches lying around:
* Allow files in CLISH_PATH
* More flexible composition
* Allows dealing with plugin conflicts (python2/3)
* Eliminate need for STARTUP
* Provide hard-coded default prompt
* Use view from command-line
* Experimented with default to global view
* Really not a nice thing to do
* Willing to just default to "main"
* Writing a common "main" module library
* Provide some standard types
* Provide a default "main" view
* Serves as basis for defining plugin utilities
* Python debugging module
* clish debugging module?
* Makes module-collections composable
* Examples should use this uniformly

[Serj Kalichev]

The document describes some aspects of future new klish.
https://src.libcode.org/pkun/klish/src/master/docs/specification.ru.md
I hope something like google translator will help to translate and
understand it. I have no such document in english now.


13.10.2020 07:06, Ingo Albrecht пишет:

[Ingo Albrecht]

On 10/13/20 3:47 PM, Serj Kalichev wrote:
> The document describes some aspects of future new klish.
> https://src.libcode.org/pkun/klish/src/master/docs/specification.ru.md
> I hope something like google translator will help to translate and
> understand it. I have no such document in english now.
>

Thank you for the notes! It is good to know where you are headed in some
more detail. I will take it all under consideration.

They translate well enough. I don't speak Russian, but I know enough to
piece things together so they make sense.