[PROJ] RFC4: last chance to comment before motion

[Nyall Dawson]

> Would the following function be useful ?
>
> /** Download a file in the PROJ user-writable directory.
>  *
>  * The file will only be downloaded if it does not exist yet in the
>  * user-writable directory, or if it is determined that a more recent
>  * version exists. To determine if a more recent version exists, PROJ will
>  * use the "downloaded_files" table of its grid cache database.
>  * Consequently files manually placed in the user-writable
>  * directory without using this function would be considered as
>  * non-existing/obsolete and would be unconditionnaly downloaded again.
>  *
>  * This function can only be used if networking is enabled, and either
>  * the default curl network API or a custom one have been installed.
>  *
>  * @param ignore_ttl_setting If set to FALSE, PROJ will only check the
>  *                           recentness of an already downloaded file, if
>  *                           the delay between the last time it has been
>  *                           verified and the current time exceeds the TTL
>  *                           setting. This can save network accesses.
>  *                           If set to TRUE, PROJ will unconditionnally
>  *                           check from the server the recentness of the file.
>  * @return TRUE if the download was successful (or not needed)
>  */
>
> int proj_download_file(
>   PJ_CONTEXT* ctx,
>   const char* url_or_filename,
>   int ignore_ttl_setting,
>   int (*progress_cbk)(PJ_CONTEXT*, double pct, void* user_data),
>   void* user_data);
>

yes -- that looks handy! The only thing I'm unsure about is whether
we'd also need a call to determine in advance IF a download is
required (so that we can alert the user and then trigger the full
download in a background thread)

> That said, I can anticipate issues on Windows in the situation where a PROJ
> pipeline would have a grid opened from the PROJ user-writable directory,
> and someone would call proj_download_file() on that file, and it would be
> determined that we have to update it. We would not be able to replace
> the file, because it would be already opened. So we would probably need some
> logic to use a different local filename for the most recent version, store in
> the database the most recent local filename, and the deprecated one(s), and do
> cleanup when we can actually delete files... (reading a bit on the subject,
> it appears the FILE_SHARE_DELETE flag of the Win32 API OpenFile() wouldn't
> even solve the issue, as it allows to delete a opened file, but not to create
> a file with the same name while the old version is still opened, contrary to
> POSIX unlink())

Wouldn't this be an issue with the on-demand grid downloads too?

Nyall


>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com