Restructure config parser.

Currently, there is one configuration file containing both the printer and the format specifications.

How do we declare information that may change independently from the printers capabilities?

Such as the name of the printer or the printing mode we want to use for the current run.

Currently, both are declared in the printer configuration. But from my point of view, the printer configuration should not include those values.

Georg

Solution:

• Give possibility to separate config files via include
• Add method to override properties from CLI

Yes, we should rethink this. A very valid point was to split the printer and format config, which will be done soon.

A thing I don't understand is how you'd want to exclude printer.name from the config? The printer config should describe all properties that will typically not change. The device name is one of them IMO. Including it has the positive effect that by specifying a printer config when running the app automatically identifies the output device. The alternative would be to specify one parameter for the config file and another one for the name, which is redundant because they would always be used as a pair. You would not really want to target a specific embosser with the configured abilities of a different embosser..?

For the printer.mode I am not quite sure. I see your point, but I would not completely remove the property. I would instead leave it as a default setting which can be overwritten by passing a parameter to use another mode. An alternative would be to keep the property as a list of modes that are available to the specific embosser.

mentioned in issue #28 (closed)

mentioned in issue #27 (closed)

My idea was: The printer configuration is tied to a specific embosser model and its capabilities. That way, those files are interchangeable between different systems without the need of any modification and we can include those files in the packaged jar file. (see #23 (closed) and !8 (comment 62867))
When you hardcode environment specific details into the files, like the name of the printer, this system does not work.

As for the modes: We can list the supported modes in the printer config, as they are dependent only on the printer model.
We can however add a default mode (globally/in each format) to avoid attaching a command line parameter on each run.

So the user will select a printer model and the name of the concrete output embosser via parameters?

Also I would set a global default mode instead of a format specific one. IMO the mode is not a format specific setting. You can use a normal printing as well as specialized implementations on the same format, the difference lies in the way how the implementations generate content that conforms to the given format.

Example: Rasterizing in normal mode will create a margin by omitting some cells (leading to a margin size which is a multiple of the cell size) while plotting in floating dot mode will create a much more exact margin because of higher available resolution. The underlying format however is always the same.

I guess we can agree on a global default.

added Feature update label

added Doing label

I created the branch feat/configparser-update-29 to implement the discussed changes. For now I will separate printer and format config as it is already agreed upon.

Would it suffice to rename printer.mode to printer.modes and change the validation to accept a comma separated list?

We could also keep printer.name as a field that contains the name of the specific model (not the actual device name) or we could completely discard it.

It would be beneficial having the model written somewhere in the file, additionally to the file name.
If this is solved by a special attribute or a comment is up to you.

If a list is supported in java properties, that would be the way to go.

If not, we can use a boolean value for each mode.

Now that I really think about how to implement this update, I really see a lot of questions.

Do we separate printer and format config in a way that we have one single config in which all formats are defined or do we split it into a single file for each format? This change is bigger than thought first. Please note that splitting printer and format config invalidates the use of the config namespaces, splitting the formats even further into single config files invalidates the use of the format name prefixes.

It also makes it possible to combine every embosser model with every format, which was not supposed at the time the config structure was designed. It would require to add a further property to the printer specifying which formats are supported. But what about user defined formats now? The format config gives the ability to specify arbitrary sizes and margins. I see that it is possible to standardize the sizes (A5,A4,...) but what about the margins?

I start to question the idea of restructuring the config a bit.

The benefit of having separated printer and format configurations was, that we limit code duplication, right? Was there any other motivation?

I personally have no problem with giving the user the ability to combine printer configurations with format configurations, that do not match and thus create runtime errors or gibberish printer output. If he does so, it's his own fault, there is no security risk involved here.

I can however understand if you don't agree on this point of view, for example from a usability perspective.

Well I understand the point but I see that time is running out and this would be a quite big change. An idea for compromise: We add the possibility to include configs in each other to minimize the duplication.

I think normally a user only uses one printer model. It'd be rare to have multiple models lying around and switching between them (like us). So normally a user would be fine to just create a specific config file for his printer model, with his environment specific data and the formats he needs. We could deliver predefined files for different printer models and just leave the environment specific properties empty, making the user set the values when he first uses the app.

If however a user needs to have two separate configs for different models he can just include an external format definition.

The Java Properties Syntax would allow something like this:

include file1,file2,...

where include is simply read as a property key and file1,file2,... is the value which could then be parsed as a list of further Java Property files.

I think this solution would be much more simple, fast to implement and gives the possibility to split the config in any way you want to.

Maybe for the printer.mode property we could offer an optional parameter to override the value from the config. That way a user can quickly switch it on each run.

That's a pretty good idea.

changed title from Discuss the puropuse of different configuration files once and for all to Restructure config parser.

changed the description

added Review label

removed Doing label

changed milestone to %Supersprint

closed

removed Review label