<br><br><div class="gmail_quote">On Tue, Mar 16, 2010 at 4:31 PM, Frank Warmerdam <span dir="ltr">&lt;<a href="mailto:warmerdam@pobox.com">warmerdam@pobox.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">


With regard to the fixed vs. mixed resolution results, it is true<br>
that the current API provides no mechanism to request particular<br>
levels of completeness, such as passes in an interleaved progressive<br>
display.  I imagine this issue was not addressed in part because<br>
it has no applicability to the JPIP case.  I&#39;m not at all clear on<br>
how important it is.<br></blockquote><div><br>You might have guessed that it a technique I use in my own applications. This could also allow notification for tile/block completion among other things. I am not sure how JPIP is implemented in GDAL but it seems that only a fixed window and resolution are allowed at a time I am not sure if the image data itself can be progressive. However JPEG (maybe JPEG in Tiff?) and PNG support progressive data. Loading a GeoTiff I would want to know when a tile read was complete.<br>

</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
I still didn&#39;t quite grasp why an event/callback approach is better<br>
than GetNextUpdateRegion() style polling to handle distinct levels<br>
of completeness, nor what you mean by mangaging the I/O budget.</blockquote><div class="im"><br>The timeout passed to GetNextUpdateRegion is abstractly thought of as an I/O budget. In this case it is constrained in time. On a related note the RFC does not specify when GetNextUpdateRegion would return besides the expiration of the timeout and end of stream.<br>


<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
2. There is no consideration or mention of how this would work with<br>
user managed I/O if that ever happens. I would like to eventually see<br>
a GDAL/OGR user managed I/O in both push and pull forms. Asynchronous<br>
I/O and user managed I/O have implications for each other.<br>
</blockquote>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I&#39;m not sure what you mean by user managed I/O.  Do you mean applications<br>
providing their own low level IO handlers - for instance to the VSI*L<br>
layer?  I&#39;m not sure I see the relationship between the progressive data<br>
api and managing IO.<br></blockquote><div><br>Right, I mean when the user feeds data (push) to a driver or a I/O handling object (pull) like VSIVirtualHandle (preferably with a C interface). This would interact with async I/O because it would affect the I/O state and enable a graceful read interruption. For example if a synchronous read does not return the expected number of bytes in the current GDAL my guess is that would cause an error condition. In an asynchronous read there is no completion expectation so a PENDING could be returned. That type of behavior was not captured in the RFC.<br>

<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
I appreciate your feedback though I am concerned that you are raising<br>
pretty fundamental changes in the implementation.  I&#39;d want pretty<br>
compelling reasoning to start over.</blockquote><div><br>I don&#39;t think a rewrite is at all required to implement some of these suggestions. If it would be helpful for me to demonstrate how to derive the same GetNextUpdateRegion interface from a callback style interface.<br>

</div></div><br>Aron<br clear="all"><br>-- <br>Aron Rubin<br>Handy Husband &amp; Daddy Jungle Gym &amp; Senior Engineer<br>