These are some facts that may need some discussion or thinking: --------------------------------------------------------------- * A parameter represented as STDIN does not have the same flexibility as outher inputs. It is always supposed to be "direct data". It would be nice, even for this type of input, to be able to give data by reference. But that would need a change in the ACD->XML parser (I believe). * There may be few not-fully finished issues with the synchronizations of job states and job reports when accessing the same job from several different JVMs. At the moment, it does this: - The job state is synchonized, which means that any JVM that changes a job state is going through check in the FileStorage (a persisen storage is the only place where the synchronization of two JVMs can happen) not allowing to overrite lower job state by a higher one. - Also a check is done for the last event that the persisten storage keeps really the latest one (checking it by comparing timestamps of two events before overwritting one). - The 'report' result is not synchronized (otherwise we could loose a richer report and replace it with later oane but with fewer facts). If we would like to change this, we would need to store individual report properties and re-create a report by merging them etc. Too wokr for little rsult (I concluded). - There may be places for some optimalization (when we find this is a bottleneck): i) The JobState can synchronized only after a (short) period a time - it would save going again and again to the persisten storage; ii) Perhaps also the Reporter can optimized by sending a new report to the persistent storage only after a (short) delay - so more report properties coming in a sequence will be written only once. * The Config reads properties and has many options how a property can be recognized, using various prefixes that narrow properties to specific services or classes. But so far, in real life, the class prefixes are not that often. So if, in the future, we find that this slows down the Config too much, we may introduce a new property "do.not.use.class.prefix" - when it is set to true, the class prefix will not be tried.