Changes between Version 18 and Version 19 of rfc24_progressive_data_support

Timestamp:

Aug 27, 2008, 1:22:02 PM (16 years ago)

Author:

normanb

Comment:

--

rfc24_progressive_data_support

@@ -51 +51 @@
 ''Response'':
 
-This is the big question, since within jpip (and other streaming protocols) this is handled at the dataset level as opposed to the band level.
+This is the big question, since within jpip (and other streaming protocols) this is handled at the dataset level as opposed to the band level.  Within JPIP the returned bands are specified using &comps=x1,x2,x3 ... as request to the server, it would not be desirable to make 3 separate requests to the server to make an rgb image (though you could).  As such recommend that the band level access subscribes to the parent dataset for accessing the server, and that the band data is pulled from the dataset class - this is potentially the hardest part to implement, and will be deferred until the dataset access level is complete.
+
+''Question'':
+
+Supporting the the current synchronous mode in addition to the asynchronous rendering mode.
+
+''Response'':
+
+Can you point me to some more info here, are you discussing the asynchronous and synchronous jpip streams as per the JPIP spec?  If so then we would only support the synchronous mode of JPIP communication - this is the most commonly deployed.
+
+''Question'':
+
+With regard to the SWIG / C API would this be supported by means of adding a new function name to the API like GDALBeginRasterIO or GDALAsyncRasterIO for instance?
+
+''Response'':
+
+I am thinking SWIG directors, so the overloaded RasterIO function accepts a function from the calling language.  
+
+