Re: Selective transfer
Selective transfer rules were originally designed to be completely separate from queue files, thats the beauty of them, you can change them on demand without having to worry about them being linked to a queue file. Allowing a single queue file to be used to perform multiple specific tasks based on which selective transfer rule set is active.
In 4.0 we added the ability to bind a specific selective transfer rule to an individual item within the queue, this provides additional flexibility for scheduled tasks where a single task could then be used for multiple specific tasks.
I completely understand your point of view and there are some situations where it would make sense to allow binding of the current selective transfer rule to a queue file. However this poses a complex problem of how to determine when these rules should be stored as part of the queue file.
I suppose the user could be prompted after selecting a rule set and asked if they want to bind the rule set or just use it for the current session. However this could become a tedious task of always clicking yes or no each time the user changes the rule set.
A global setting might not be practical because of the over-all impact of such a feature. The user would need to be aware of which rule set is being used at all time.
Is there any specific reason you use a selective transfer rule set instead of a per-site skip list?
|