Switch to a more modular architecture

[bernardpaulus]

scriptim might be suited for a pipe-and-filter modular architecture.

That is, a chain of modules, transforming step by step the user input until either one of the modules executes an action (i.e. calling a function like reset(), exit() or sendCommandAPDU() ). This is like layers

Modules could be organised in zones, and each of those zones would be delimited by a terminal module:

• zone raw input : modules can work on the raw input. It finishes by module UnComment, who would uncomment the string
• zone EOF string : command is a string without comments, or can still be EOF (None). Finishes by module TreatEOF
• zone uncommented string: command is a string without comments. Finishes by module Tokenize.
• zone tokenized/no token : the modules are working on a list of strings, that can be empty. Finishes by module NoCommand
• zone tokenized to hex representation: the command is a list of strings, that can be transformed even further. The last module of this section should only see a list of string representations of hex, and convert it to binary data. That is module HexBin.
• zone binary data : the modules work directly on the binary data. However, the only module I can think about for this zone is the module that effectively sends the APDUs, APDUSender.

Each module can throw exceptions in case of errors. Those exceptions should be catched and the original input string should ideally be reconstructed back. The simplest way to do this is that each module keep a copy of it's input and output for the current command. Other ways are possible.

Additionnaly of the error location should be pointed where it occurs in the eye the module that normally provides input for the current module, if the current modules performs a transformation.

For example, a module performing an expansion of a command into multiple "0" should indicate the location of the "0"-generating command to the upper module if there is an error due to one of the "0"s.

A similar output chain in reverse might be a good idea for the output.

Finally, a single module could be part of input and output chains, actually sending another command down in the input chain upon reception of the response of the current command in the output chain.

This opens the way to scripts to help the user. We could have, as example, the two different APDU commands like reading the tag and displaying the data read done in go for the user.

Modules could also react differently according to the reader, or the tag inserted.