On Tue, Mar 23, 2010 at 4:41 PM, Romain Beauxis <[email protected]> wrote: > annotate is registered as a post_processor, I believe it is more relevant (in > fact we may eventually remove the .ml and put it in utils.liq)
Annotate could be either type, but post_processor makes more sense. However, I think it's nicer to do the parsing of the metadata in ML. > As such, the post-processors have a strict specifications about the indicators > they push: it should be temporary = true iff they create a new file, and in > this > case *always* create a new file. Here is what I had in mind. This might be wrong but should somehow correspond closely to the old code: A downloader sets temporary iff it created a new file. I would expect that the post-processor can modify a new file in place, leaving the temporary flag. In fact, *we can't support the creation of two temporary files* (that's why this temporary flag on any indicator is a bad design... could we improve?). If the post-processor wants to create a new one it must remove the old one, and leave the temporary flag for the new one. If the post-processor doesn't change the file (e.g. annotate) it shouldn't change the temp flag. If the file is not temporary it should not change the file, but always create a new temporary one. > That way, the issue of cleaning temporary files is kept local to each > indicator. This leaves me thinking that you have another idea of the cleaning process (maybe you changed the code already, I didn't look again): currently, I believe only the last indicator is cleaned. Do you want to support multiple temporary files and clean them all? Isn't it better to clean the intermediate ones as early as possible? > Hence, annotate will operate on a uri which is now the local file. I never > create a new file, so the indicators it return should force temporary to > false.. This confirms my impression. You mean that you create a new indicator that doesn't have the temp flag, so the file is not deleted, and it can be properly deleted when the next indicator is cleaned. Once we get the high-level idea right, we might come back to more technical questions if they are still relevant. Finally, there's a naming issue: I don't think resolver is an intuitive word for most users, I prefer add_protocol to add_resolver, although we could also think of add_downloader. Cheers, -- David ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Savonet-devl mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/savonet-devl
