[gdal-dev] vsipreload: enabling VSI Virtual File API for regular I/O

[Howard Butler]

On May 28, 2013, at 12:59 PM, Even Rouault <even.rouault at mines-paris.org> wrote:
> Yes exactly, my examples were supposed to illustrate the use cases where it 
> was needed. A few drivers do not support the /vsi file systems because they use 
> directly the standard IO functions and provide no way of redirecting them 
> through the VSI virtual file API, because their underlying library doesn't offer 
> this capability.

Sorry I didn't read far enough down to the examples. I saw "preload" and ".so" and immediately thought of symbol chicanery in the context of tracking memory allocations and the like, not twisting curl'able datasources into FILE*'s.

Now that I have your attention, I brought up with Frank at FOSS4GNA that there could sometimes be a need for both MEM drivers to spool off to disk through some sort of out-of-core mmap'd allocation. Does this currently exist in VSI, and if not, do you see any use for such a thing? My thought was there might be scenarios where someone working with multi-gb (or worse) raster data sources where you'd like to control the paging (ie, you have SSD, or you want to create intermediates for some weird processing chain). Maybe not all that useful in exchange for the added complexity...

Howard