On Fri, 21 Jan 2011, Hans Hagen wrote:
What exactly do you mean with the suffix issue?
Consider \externalfigure[http://contextgarden.files.wordpress.com/2008/08/logo-alt41.png] The current implementation downloads this file as <path-to-current-cache>/http-contextgarden.files.wordpress.com-2008-08-logo-alt41.png Then external figure sees a file with .png extension, and correctly includes it. If you follow my suggestion, the file will be downloaded as <path-to-current-cache>/667816068B899068327DA1EF013B3943 Then external figure sees a file with no extension, assumes that the file is a pdf file, and the figure inclusion fails. To correct that, you need to add [method=png] to \externalfigure.
We can probably normalize things a bit.
Agreed. Perhaps the best option will be a file name like http-contextgardent.files.wordpress.com-667816068B899068327DA1EF013B3943.png (so normalized base url + md5sum of url + extension). I am not sure how if extensions can be calculated reliably in urls. In particular imaging something like http://www.bing.com/search?q=check+.extension+long+url+so+that+os+filename+l....... A simple algorithm with assume that everything following the dot is the extension, while that is certainly not the case here. We can definitely restrict the search of extension to the last 10 or so characters of the url, but there will be cases when such heuristics will fail.
Concerning the gibberish ... we can put a file alongside with some info. I need to think a bit about it but indeed it makes no sense to have redundant mechanisms.
Thanks, Aditya