[gdal-dev] GDAL Progressive Data Support RFC Discussion

[Frank Warmerdam]

Even Rouault wrote:
> * I've skimmed the past discussions on RFC24 and I see one of your remarks 
> was "The GDALAsyncRasterIO object should be renamed GDALAsyncRasterReader or 
> something that does not imply that writing is supported unless that is 
> intended for the future". Perhaps that we can leave the name of 
> GDALAsyncRasterIO/BeginAsyncRasterIO() but introduce a GDALRWFlag eRWFlag 
> parameter as first parameter of BeginAsyncRasterIO() if we want to allow 
> future use for writing ?

Even,

I agree.  I am renaming everything to AsyncReader instead of
AsyncRasterIO.

> * LockBuffer() / UnlockBuffer(): the RFC says "The LockBuffer() and 
> UnlockBuffer() methods can be used to temporarily disable updates to the 
> buffer while application code accesses the buffer". Shouldn't it say 
> rather "... *should* be used ... " as the user has no way to tell if the 
> driver implementation makes it necessary or not to use 
> LockBuffer()/UnlockBuffer(). 

I'm a bit lost in the distinction.

> * Shouldn't LockBuffer() have a return code instead of void ? In case the 
> underlying locking primitive fail. Shouldn't LockBuffer() have a timeout 
> parameter for consistency ? Or we want it to wait for infinite time ?

Yes, this is reasonable.  I will change it accordingly.

> * The timeout parameter of GetNextUpdatedRegion(). This is related to the 
> meaning of the timeout parameter of the related CPL primitive 
> CPLAcquireMutex(). 
> 	-  I notice that CPLAcquireMutex() use a dfWaitInSeconds parameter : wouldn't 
> it be more consistant to use it also for GetNextUpdatedRegion() ?

I agree, I will change to a double precision value measured in seconds.

> 	- Shouldn't we have a special constant meaning infinite waiting, instead of 
> using arbirtrary numbers such as 100.0 used in 
> JPIPKAKAsyncRasterIO::GetNextUpdatedRegion().

I will change it to use -1 as a special infinite value.

> * BeginAsyncRasterIO() : neither the RFC nor the doc of the method explains if 
> it is legal or not to initiate multiple AsyncRasterIO() without waiting the 
> first ones to be termintated before beginning a new one. My understanding of 
> the JPIPKAK driver is that this particular driver allows 2 concurrent 
> AsyncRasterIO(). Perhaps just adding a note in the doc of 
> BeginAsyncRasterIO() to say that this is a driver specific behaviour might be 
> sufficient. In which case, the doc should probably add "@return The 
> GDALAsyncRasterIO object representing the request or NULL if the request 
> cannot be started". (by the way, it might fail for other reasons such as 
> wrong parameter values)

My thinking was that an application could have multiple asynchronous
requests active at once and that the limitation to two is just a
peculiar limitations of the JPIPKAK implementation.  I've got an email
out to Norman to see if there is any reason to avoid generalizing this.

I'm going to avoid adjusting the docs and RFC till I hear back.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent