Yo, On Sat, Mar 20, 2010 at 10:47 AM, Romain Beauxis <[email protected]> wrote: > * I do not think there is any way to know whether a file is temporary or not > when handling it in the resolution process. This is a problem because the cut > protocol may cut a temporary track, and in this case need to remove the old > file, or cut a static file, and in this case should not touch it.
You're right, and it's even worse than that: the design originally relied on the assumption that only the last protocol allocates a file (the "temporary" cleanup system doesn't treat a stack but at most one file). What you're trying to do, like replaygain, is hackish in the current design -- in fact I just looked at the code of annotate and it is hackish too, since it relies on the ad-hoc possibility to attach metadata to an URI. > * Also, I wonder if it would be possible to reverse the protocol resolution. > So far, protocol resolution is done from left to right. Hence, requests like: > replaygain:ftp://path/to/bla.mp3 > do not work. > Could it be possible to reverse the resolution and start with resolving ftp: > first and then pass it to replaygain ? The only protocols that take another URI as parameter are replaygain, annotate and your planned cut, so the order is only relevant for them, and the order you propose is the right one for them. So your proposition seems relevant. However, the real problem is to know if the argument of an indicator is supposed to be another indicator. If I write "http://foo:8000/...";, there is a risk of seeing a nested indicator "foo:8000/..." (the // prevents it but it's just luck). The point is that only the protocol knows if its argument is an indicator. Hence a different proposal: let such protocols perform the resolution of their argument indicator. This would currently require to create a new request and resolve it, which is a bit unsatisfying. That might call for more power to the protocols, e.g. direct access to the request being resolved, as you proposed in your first point. This first solution has the disadvantage of breaking modularity, allowing all kind of stuff to the protocol resolvers, and might not even be so convenient. Another way to go is that such protocols don't reply with a new indicator, but also with a continuation that should be applied to the request once it's resolved. This is more appealing, although it still allows all sort of wild behavior. HTH 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
