REMINDER: Final review of VCS interfaces

[Andreas Pakulat]

On 27.05.07 11:06:21, Robert Gruber wrote:
> On Thu, 24 May 2007 22:38:38 Andreas Pakulat wrote:
> > On 24.05.07 22:10:34, Robert Gruber wrote:
> > > I've planned to do the porting of the CVS plugin. I just didn't start 
> > > yet, because the interface was still changing a lot. As soon as we 
> > > decide that the interface is good enough to give it a try, I could 
> > > start implementing it almost right away.
> > > But I have no objections if want to do the porting.
> > 
> > Ok, thats nice. I just "volunteered" because Matt was kind of
> > complaining and I had something in the back of my head that you don't
> > have much free time to hack on cvs plugin. So if you have the time
> > please port it yourself, as I said I'm not that familiar with cvs
> > anymore and I don't know the code so you'd be faster done.
> 
> I tried to start implementing the new IBasicVersionControl interface in the CVS plugin. But got stopped at the very beginning. This was already issued some time ago, but somehow nothing happened. All methods return a VcsJob object, but they return it as value. Wouldn't be returning a pointer be better? 

Right, seems like nobody actually did it, although we all agreed on
that.

> 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)

Andreas

-- 
You will have good luck and overcome many hardships.