[Qgis-developer] API changes

[Martin Dobias]

Hi Marco,

great! I have just few comments:

- is it necessary to call reset() everytime after select() ? It would
be simpler if users could do just select() and then getNextFeature().
If provider needs to call reset() first, it could be done in select().

- getNextFeature has parameter featureQueueSize. I think this
parameter is quite misleading, unused by the code and most providers
don't use it. I would suggest removing it and let's use some
predefined value for postgres.

If you won't mind the proposed changes, I'll do them. Then we could merge.

Martin

On 4/2/07, Marco Hugentobler <marco.hugentobler at karto.baug.ethz.ch> wrote:
> Ok, I changed the provider interface of the functions 'select'
> and 'getNextFeature' and also the related code of the qgis core and the
> individual providers.
>
> I suggest to merge the branch back soon. This still leaves some time to test
> for new bugs.
>
> Regards,
> Marco
>
> Am Freitag, 30. März 2007 18:02 schrieb Martin Dobias:
> > On 3/30/07, Marco Hugentobler <marco.hugentobler at karto.baug.ethz.ch> wrote:
> > > Hi Martin,
> > >
> > > The interface looks good.
> > >
> > > It would be nice if getNextFeature could be const, but that would
> > > probably require some members of providers declared as 'mutable'.
> >
> > I don't think this is possible: with every getNextFeature() provider
> > changes its internal state as it must increase the counter (or
> > delegate that to backend).
> >
> > > > Also it might be good to think about enabling concurrency as currently
> > > > it's not possible to do more data retreivals at once with one
> > > > provider. Iterator design pattern could solve this situation, the
> > > > question is whether also provider backends support concurrency (e.g.
> > > > OGR).
> > >
> > > This would be a very clean solution. However, it is probably a bit too
> > > much for now. What are the use cases you have in mind for concurrency?
> > > Something like multiple canvases sharing one data provider (and possibly
> > > multithreaded)?
> >
> > One such scenario is a server application that does some processing
> > (or rendering) in several threads. Another case is the one you've
> > mentioned - in future we should do canvas rendering in a thread so
> > that GUI won't freeze every render. And with more canvases we would
> > get into troubles.
> >
> > But you're true that this would need some more time.
> >
> > Martin
>