Architectural issue: STARTUP considered harmful

[Ingo Albrecht]

Hey again,

Another discussion topic that I've found in notes of mine, typed out in
quickhand for the record.

=========================================================================


== Use case: making modules truly modular

Various uses of clish can be catered for by combining several sets of
command definitions from different sources.

A module library might limit itself to it's own view or work with shared
well-known verbs (show, set, clear...) that come from a set of base
definitions (which currently does not exist). Both cases are easily
realized.

One use example would be a combination of my klish-system collection
with some appliance-specific modules to create an appliance shell.


== The problem: STARTUP considered harmful

Unfortunately there is a little snag in this story:

Currently clish requires a STARTUP tag, and there can only be one. The
modular way of dealing with this is to put it in a "main" xml file. This
however implies that any directory containing a STARTUP definition
cannot be used in free combinations of CLISH_PATH entries. The only way
of dealing with this right now is to create an extra directory for this
file to allow use in both ways - independent and modular.

There are possible solutions, but in current pre-refactoring clish it is
not easy to implement a truly nice solutions.

== Proposal #1: Allow XML files in CLISH_PATH (not only directories)

This simplifies things a bit by no longer forcing the user to create a
directory just for one module file.

It's easy to implement even before the refactored branch exists.

== Proposal #2: Eliminate requirement for STARTUP

In truth STARTUP does not do much. The need for it can be eliminated,
but there are currently some snags which is why I didn't propose patches
for this overall issue yet.

The following things need to be taken care of:

==== Default VIEW

The startup section defines the default view, which is the hardest thing
to replace well because of how clish context handling currently works.

In principle there isn't much of a problem here. There are two options I
can think of:

1) Use a name like "main" as the built-in default.

Most XML definitions should use that view for almost all commands.

In effect this is what others call the "operations" view.

There are options for view and viewid to override this already, so the
default won't hurt the user in any way.

2) Use the global view as the default view.

This makes some sense but doesn't work well in combination with modular
commands because any command in the global view is truly global.

There should never be much more than "quit" and "history" in the global
view, which in practice is never useful.

==== Default prompt

Chosing the default view implies chosing the default prompt.

Since view prompts are actually optional it is currently possible to
start clish without a prompt. This of course makes little sense.

There should be a simple default like ">" or ">>>".

In fact there should be a default prompt both in clish and in tinyrl for
some reason that I forgot, but I have patches somewhere for it.

There should also be a builtin for overriding the prompt and viewid.
Another option would be to provide an environment variable.

==== STARTUP action

STARTUP contains startup code that really belongs in view startup ACTION
or plugin startup CONFIG (which could more nicely be an ACTION) - this
is easily replaced by introducing view actions as I proposed previously.

==== DETAIL element

The DETAIL element really is a special-case hack and should be eliminated.

There are many alternatives such as using "echo" or "cat".

One can also imagine a builtin that simply prints it's contents after
expanding variables - if it doesn't exist already.

The generalized solution would be to have a generic TEXT element that
can be referenced more freely, but I don't want to bike-shed this.

[Serj Kalichev]

Hi

May be the right way to consider STARTUP is a integration of modules and
entry-point?

The existence of multiple xmls with STARTUP tag  is really problem. The
possible way to solve problem is symlinks. Directory with symlinked
modules and STARTUP's xml.

XML-files within CLISH_PATH is good enough.

The default "main" VIEW solves nothing. Because modules doesn't know
exactly how they will be used. In my opinion the right way to use
modules are NAMESPACEs. It's not good for modules to use predefined VIEW
name.

Consider the C programms and C libs for example. C lib has no main()
function but executable binary has. It integrates all libs. Why is it so
bad?

May be the right way is to create special klish 'profile' that list all
needed XMLs, starting VIEW and so on. User executes klish with link to
this profile. Profile can be the same as a main() for C. Or may be
profile is XML file too. But it has all needed information internally.

# clish --main=router.xml
Profile define the whole functionality of klish session.



20.11.2020 19:15, Ingo Albrecht пишет: