REMINDER: Final review of VCS interfaces

[Matt Rogers]

On Sunday 27 May 2007 16:29, Andreas Pakulat wrote:
> On 27.05.07 09:01:44, Matt Rogers wrote:
> > On May 27, 2007, at 4:48 AM, Andreas Pakulat wrote:
> > > On 27.05.07 11:06:21, Robert Gruber wrote:
> > >> I'm still not sure about returning VcsJob anyways. For example in
> > >> cvs plugin I'm using my own CvsJob class which is derived from
> > >> KJob and therefore already provides all that stuff from VcsJob. So
> > >> why don't we just return a KJob pointer? Or maybe derive VcsJob
> > >> from KJob, which will make the start and cancel slots and the
> > >> signals needless as they are already provided by KJob.
> > >
> > > Because KJob doesn't provide an API that is usable. VcsJob should
> > > either
> > > be a pure interface which you inherit from additionally to KJob or it
> > > should be a KJob subclass. I'm not sure which approach is better,
> > > didn't
> > > really look into that yet (but I'm guessing the second one)
> >
> > How is it that KJob does not provide an API that's usable considering
> > there are plenty of places it's used throughout KDE? We need to
> > derive VcsJob from KJob.
>
> 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)
>
> Andreas

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?
-- 
Matt