> Deelkar wrote: Matthias Julius wrote: > > And I do agree, the directory usage structure needs an overhaul.
Agreed, I was also very close to tackling this :-). I had started by reducing some of the unneeded temporary files. I propose to create a temporary dir in WorkingDir and use that for all files temporary. The tmpdir could be set as attribute to the Request object (that would fit, wouldn't it?) and would thus be passed around. A s suggested earlier, that directory is just deleted after successful rendering (or kept around in Debug mode). > I am planning to work on that because I wanted to prepare the client > for the "download while rendering" feature Spaetz requested. Hehe, *suggested*, I suggested, not requested that :-) > In the mean time I was so annoyed by the lack of a decent exception > handling in Perl that I was almost ready to re-implement the whole > thing in Python (which would also have the potential advantage that > some code could be shared between the server and the client). I have the zipping and uploading code ready in python if you need it. It's even threaded already :-). You just need to plug in the magic rendering part. I somewhat dislike introducing new perl dependencies (make installation ever more difficult), that's part of what makes python so charming. "It comes with batteries included". But seriously, we depend on perl for or/p and preprocessing, so it would not make sense to use another language (except if you would also provide or/py ;-) ). Besides, deelkar is not very comfortable in python, I believe. > But, after that I found the Error module on CPAN which implements this > and I want to give it a try if nobody objects. What exactly is it that perl::Error gives us? One thing that strikes me as insufficient currently, is that a CTRL-C in inskscape (or or/p) will hand back jobs as "BadSVG" or "RenderFailure", which is very misleading. But I think we are able to capture those exceptions with perl standard means, perhaps others no more about that. It would be great if we could hand back a job as "UserAborted" rather than misleading error messages. All in all, I am very happy with the direction the code evolved during the last weeks, even if it implied an occational unfortunate breakdown for renderers while we had things botched up. I blame it on the OSM Foundation's QA department :-). spaetz P.S. Matthias, you created lib::tahconfig.pm, and there is also tahconfig.pm. Do you plan merging these somehow? Or some of it? _______________________________________________ Tilesathome mailing list [email protected] http://lists.openstreetmap.org/listinfo/tilesathome
