Runping Qi wrote:
This sounds good to me! A couple of questions.
If the user uses the default JobInput implementation, how does the user to
specify the input directory? Currently, it is done through methods of
JobConf. Will that change?
The default JobInput should be back-compatible. We could decide to
deprecate JobConf.setInputDir(), and encourage folks to use an
JobInput-specific method.
But we don't expect end users to be implementing JobInput. Rather, they
might job.setJobInputClass(MultiJobInput.class) and then use a static
utility method like:
void MultiJobInput.addInput(job, dir, recordReaderClass, mapperClass);
But can the end user implement such a class if s/he wants to? In other
words, will the user have only two choices: the default implementation of
JobInput
and MultiJobInput? Or the user can implement his own:
public class MyMultipleInput implements JobInput {
};
Sure, that's the idea, to give more flexibility to those who need it.
Doug
