VCS Interface classes (async execution)

[Matthew Woehlke]

Jakob Petsovits wrote:
> On Monday, 30. April 2007, Andreas Pakulat wrote:
>> I present to you our new VCS interface classes (that I finally managed
>> to write up, based on the enourmus thread some time ago).
> 
> Other question: is it ok to let each VCS plugin reinvent threading?

Andreas brought up the idea of using KJob. Probably you will not 
reimplement threading, but use some standard job class.

> Is it really necessary to let plugins keep track of their action calls?
> How long after the call are they supposed to keep the action ids?

I don't think the plugin needs to keep track of its calls at all, that's 
the caller's responsibility. Or at least it should be possible to work 
that way when we switch to jobs. Otherwise I guess it will work like 
threads, if you detach() it can discard any info about the job, 
otherwise you must wait() on the job to avoid leaking resources.

> How about defining the interface synchronous and having one threading wrapper 
> in shell itself? Like,
> 
> AsyncBasicVersionControlWrapper asyncBasicVC =
>     new AsyncBasicVersionControlWrapper (basicVC);
> asyncBasicVC->add( myDir, IBasicVersionControl::Recursive );
> doOtherStuffInTheMeantime();
> 
> Then the plugin still has to be threadsafe, but at least doesn't need to take 
> care of all that nasty stuff by itself, shell would do it for them.

I also suggested that. I don't think it's /needed/ if we can easily 
leverage a job class, but...

> As a bonus, we get proper method signatures, with typesafe, nicely documented 
> and immediately recognizable return values.
> 
> What do you think?

...personally, I'd be OK with either method.

-- 
Matthew
"Doggy!" -- Robots from Freefall (http://freefall.purrsia.com)