VCS Interfaces, round 3

[Andreas Pakulat]

On 04.05.07 13:43:22, Matthew Woehlke wrote:
> Andreas Pakulat wrote:
> > On 04.05.07 11:24:46, Matthew Woehlke wrote:
> >> ...which still leaves the question of how do you specify the limit?
> > 
> > Simple unsigned int. If its 0 fetch all revisions, any number larger
> > than 0: Fetch that many revisions from the repository.
> 
> Hmm, I guess no one will have more than four billion revisions? :-) 
> (Given that long-lived products seem to be in the hundred-thousands 
> range that is probably safe until KDE 5 at least ;-).)

Well, we can make it an unsigned 64bit number, I doubt anybody will have
that many revisions. I was just saying that its a plain number, not a
QString or some such as it really is just something for "counting".

> >> Come to think about it, it would be ideal if VcsJob provided a way to 
> >> return results incrementally.
> > 
> > We can follow QProcess here and emit resultsReady() then the user of the
> > job can fetch the results and finished() would be emitted when the job
> > is completely done.
> 
> Sounds good. I assume resultsReady() is fired 0 or more times? (I.e. 
> keep firing it at results come in, possibly rate-limited? The rate limit 
> would also be nice if the operation completes really fast, you would 
> skip right to finished().)

No, resultsReady would always emit at least once, unless there are no
results on an action (think add, commit and so on).

> >> Support would be optional, but if 
> >> available it would allow
> > 
> > Uhm, the signals wouldn't be optional, but if the backend doesn't allow
> > to send intermediate results it would send resultReady() just once and
> > finished() immediately afterwards.
> 
> That's what I meant. If it doesn't know how to give intermediate 
> results, it never uses that signal. :-)

No, if an action returns data it emits resultsReady at least once (with
the first chunk of data, which may already be the full data). 

However there we have a problem, when the job is really fast we run into
trouble because it might finish before the signals are connected. So
should we maybe have a "start" slot in the VcsJob to initiate the start
from the "user"?

> > It might however mean that the backend still
> > executes completely, just that no resultsReady signal is emitted and the
> > finished signal not either (rather a cancelled() one)
> 
> That's fine. I imagine process-based implementations will just SIGINT 
> the child in this instance.

Or sigkill :)

> Do we really need a canceled() signal?

Hmm, well that depends. Does the user care about the job after having
cancelled it? That introduces a new question: Who takes care of deleting
the job instance when its not needed anymore - the user? the plugin? I
think the user needs to do this and then cancelled is needed, you can't
just delete the job after calling cancel() else there might be uncleaned
resources...

Andreas

-- 
The whole world is a tuxedo and you are a pair of brown shoes.
		-- George Gobel