VCS Interfaces, round 3

[Matthew Woehlke]

Andreas Pakulat wrote:
> On 04.05.07 15:12:21, Matthew Woehlke wrote:
>> Andreas Pakulat wrote:
>>> No, resultsReady would always emit at least once, unless there are no
>>> results on an action (think add, commit and so on).
>> So it is (potentially) redundant with finished()? Ok, I can live with 
>> that. :-)
> 
> Uhm no. I'd reduce finished() to not carry any result info at all. I'm
> thinking about this workflow:

Er... right. I figured that out at some point, and apparently didn't 
correct myself before hitting 'send'.

>>> 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"?
>> Good catch, we'd have that no matter what, wouldn't we? start() would be 
>> fine, I'm not sure it should actually "start" the job, just flush any 
>> pending signals (i.e. the job would run right away but queue signals 
>> until start() is called).
> 
> That would make the job class quite more complex, i.e. it always has to
> check wether "isStarted" is set to know wether a resultsReady() or
> finished() signal can be sent. IMHO start() should rather start the job
> and thus the job implementation would be much lighter and easier.
> 
>> Or rather, it should be /allowed/ to do that, depending on which way
>> the plugin finds easier.
> 
> Hmm, I guess the above doesn't really matter for the user of the API, so
> yeah. Let the plugins decide what they want to do. The important thing
> to document is that no signal should be emitted until start() has been
> called, but they may be emitted from inside start().

Right.

> As I said to have a nice flow and a common point to cleanup point in
> user-code we should emit 3 signals when the job is done, that is:
> 
> a) finished(VcsJob*) - the job has finished sucessfully and all results
> are available (resultsReady signals haven been emitted accordingly).
> b) error(VcsJob*) - an error occured
> c) cancelled(VcsJob*) - the job was cancelled and is done with any
> cleanup it had to do due to the cancelling

Say, since finished() no longer has a data payload, what about having 
*only* finished() with a status code (success, fail, canceled)? That way 
clean-up can be done in one slot rather than needing to connect to three.

-- 
Matthew
Current geek index: 62%