Bla, Le mardi 30 mars 2010 11:47:18, David Baelde a écrit : > 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.
I have no opinion except that the more code we put in the utils the more examples we provide for the users.. > > 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? Well I have not looked at the code but my tests showed that all the temporary files in the stack of indicators are cleaned. I have no opinion on whether a post-processor should replace or not a file. In this case, the function should take a second argument telling whether or not the file is static. In any case we need to document it because I believe there are no easy solutions to this. > > 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. I am fine with add_protocol as well. This also avoid breaking the existing code for most of the situations.. Romain ------------------------------------------------------------------------------ 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
