Changes between Version 23 and Version 24 of rfc24_progressive_data_support

Timestamp:

Aug 27, 2008, 2:05:40 PM (16 years ago)

Author:

normanb

Comment:

--

rfc24_progressive_data_support

@@ -78 +78 @@
 Kakadu does include support for JPIP on the client (and indeed a demonstration server), Kakadu would be a good start for implementing this driver.  I would suggest a new driver called JPIPKAK just to avoid any conflict with JP2KAK.  There are issues with communication layer within kakadu, but this is relatively simple to code around using a http library such cURL.   
 
+[http://thread.gmane.org/gmane.comp.gis.gdal.devel/16409/focus=16630 Even Rouault - thread on gmane]
+
+''Question'':
+
+I would like that the dataset object to be added as the first argument of the callback, and a void* user_data to be added as the last argument
+
+''Response'':
+
+Agreed.
+
+''Question'':
+
+Is the extended version of the RasterIO() call still blocking as the current version?
+
+''Response'':
+
+This version of the RasterIO call is not blocking, the progress function is a callback which will be called when the buffer has new data.  Effectively we are adding an observer (listener) to the format driver when requesting a particular window of data.
+
+''Question'':
+
+What happens if the user specifies a not NULL argument as the output buffer ( in (1) ) ? What happens if the user specifies GF_Write ?
+It is probably an argument for a name change, something like ProgressiveRasterIO.
+
+''Response'':
+
+Agree with the name change for clarification.  There is an argument to drop the buffer and GF_READ from the function call if we are giving it a new name and not just overloading RasterIO.
+
+''Question'':
+
+Maybe it can make sense to add some way of cancelling the whole RasterIO call by providing a callback, like the standard progress callback (GDALProgressFunc in gdal.h) mechanism do ? Because the RasterIO() will spend most of the time waiting for data. It could resume from time to time to call that callback and see if the user still wants the request to be continued. It would be nice if the mechanism could provide some percentage of the total progress as it might be tedious for the user to compute that ? But that's probably not easy to define if you first update the whole request area with a low resolution, and then at higher resolutions.
+
+
+''Response'':
+
+Fully agree, adding a stop, amount of data transferred metadata would be very useful.  The driver will use GDALProgressFunc (or will now, I hadn't thought of it until you mentioned it).
+
+''Question'':
+
+What happens if the user issues another call to RasterIO(), traditionnal version and/or your extended version, in the pfnProgressIO callback 
+
+''Response'':
+
+The callback and the RasterIO function are in the same thread, so there are no synchronization issues here.  The callback function is carrying the state (so region, res, buffer etc.) so that the display thread always has knowledge of the buffer contents.  When updating the communication thread to the server, synchronization within the format driver is required.
+
+''Question'':
+
+how will that work with the block cache mechanism?
+
+''Response'':
+
+iat the moment I am not planning to integrate with the block cache, the format driver will have to implement its own (wavelet) cache this is important so  that the format driver can communicate to the server the contents of its cache.
+
+
+
+