REMINDER: Final review of VCS interfaces

[dukju ahn]

> > > I knew somebody would ask right after I sent the mail :) The thing is
> > > that KJob only provides means to start/kill/resume the job. VcsJob adds
> > > a few things on top of that (type, results, common finished signal)
> >
> > That still doesn't stop us from deriving from KJob, in fact, it's the perfect
> > case for building on top of it. Am I right, or do I miss something?
>
> Well, its not much that VcsJob can do itself, basically each plugin has
> to create its own vcsjob subclass and do a proper implementation. All
> that VcsJob can do is implement cancel() and kall KJob::kill() and then
> plugins *job subclass would implement doKill(). So I'm not sure having
> that one method implemented justifies a KJob subclass.

That's not true. Many methods are duplicated with KJob
Kjob provides finished(KJob) signal, removing the need of
void VcsJob::finished( VcsJob*, FinishStatus );
It also provides errorString(), which eliminate the need of
VcsJob::errorMessage();

Moreover the name of VcsJob::start() and exec() are same with
Kjob::start() or exec(). Plugins' *Job classes will get trouble when they
double-inherit KJob and VcsJob.

Just subclass Kjob and make other methods, such as type(), fetch()
, pure virtual. Any objection?