Changes between Version 6 and Version 7 of rfc11_fastidentify

Timestamp:

May 1, 2007, 6:31:29 AM (17 years ago)

Author:

warmerdam

Comment:

Addressed the cplreaddir/vsimem issue.

rfc11_fastidentify

@@ -152 +152 @@
  * ECW
  * EHdr
+ * RST
 
+== CPLReadDir() == 
+
+Currently the VSIMemFilesystemHandler implemented in cpl_vsi_mem.cpp which provides "filesystem like" access to objects in memory does not implement directory reading services.  In order to properly populate the directory listing this will need to be added.  
+
+To do this the CPLReadDir() function will also need to be reimplemented to use VSIFilesystemHandler::ReadDir() instead of direct implementation in cpl_dir.cpp.  The win32 and unix/posix implementations of VSIFilesystemHandler::ReadDir() already exist.  This should essentially complete the virtualization of filesystem access services. 
 
 == Compatibility ==
@@ -164 +170 @@
 == Regression Testing ==
 
-Appropriate tests will be added to the autotest/gcore directory. 
+A test script for the Identify() function will be added to the autotest/gcore directory.   It will include testing of identify in a /vsimem memory collection. 
 
 == Implementation Plan ==
@@ -173 +179 @@
 
 A very quick test introducing the Identify without actually opening changed the time to identify all files in a directory with 70 TIFF files (on an NFS share) from 2 seconds to 0.5 seconds.  So saving the overhead of actually opening files can be significant for some formats, including very common ones like GeoTIFF. 
-
-== Outstanding Issues ==
-
- 1. Is the ''sibling list'' really worth the trouble for this?  It's main benefit comes later to accelerate actual opens if functions like GDALReadWorldFile() are modified to take advantage of it.
- 2. Do we need to differentiate between situations where we don't have the sibling file list, and when we know we have it, but it is empty?
- 3. Do we need to address directory semantics in the /vsimem/ mechanism so that directory listings can be collected?