sieve uses 'require' to specify which features are needed by the script. only features specified in the basic standard are allowed unless 'require'd
ATM jsieve uses configuration files for tests, commands and comparators which match a class to a feature name. this worked fine as a way of extending sieve with new commands, tests and comparators. recent IEFT standards and proposals require more complexity than can easily be supported by this simple model. in particular: 1. the feature name declared in the 'require' statement need not match the name of the test, command or comparator enabled 2. a set of tests, commands and comparators can be enabled by a single declared feature 3. other aspects - as well as tests, commands and comparators - can be altered by a feature so, i think the current design needs to be revised since the features available depends on the script, SieveContext seems like the right place to manager them. i think it would also make sense to consoldiate the methods in CommandManager, TestManager and TestManager into SieveContext as well since these would now need to vary for each script. in terms of configuration, i think a new FeatureManager consolidating the storage and mapping functions for tests, commands, comparators and other pluggable aspects would make sense, with a Feature interface mapped to a name by a single configuration file. the most straightforward design would be to use nullable getters for each pluggable aspect each returning a map. the old properties could be supported for backwards compatibility. opinions? improvements? suggestions? - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
