I looked briefly at how you'd want to do this. The current way output connectors are designed requires either the following:
- The commit-within parameter is part of configuration information, in which case it is per-connection, not per job. But in this case a change to the commit-within info will not cause any documents to be reindexed.
- The commit-within parameter is part of output specification information, in which case it is per-job. However, any changes to the parameter will cause all documents associated with that job to be reindexed the next time the job is run.
It is also the case that the Solr output connector already has a configuration tab where a commit-within parameter would logically fit, but if output specification were used, a new tab would probably need to be introduced.
While it is possible to change the output connector API so that specification information is available directly at the time the request to add to the index is made, all this together argues that maybe we should consider the parameter to be configuration not specification information. It is, after all, "how" information and not "what". If a user needs both "urgent" and "lazy" commits, they can readily do this by creating two Solr connections. Doesn't seem like there would be too much of a downside to this approach. What do you think?