What do you mean by filter based naming? The only part that I can think of involving naming... is my rss filter example (third part). The existing filter routines already have that capability, they already have %NZBSUBJECT implemented as well. substituting a default download directory is available as well, though, maybe not as commonly used (I use it, don't know about anyone else). I was not implying to create a new feature to accomplish this (see below about the third section). My part of this request was to:
1. Detect categories based on name of collection.
2. Suggest a possible implementation of the configuration for categories, with or without matching.
3. Allow rss filters to access category variables/settings
I'll summarize and clarify what I meant by my post (my summary ended up being longer than the original post I think... but a lot more detailed). My original was mostly just examples without thought, reasoning, or background. and before I start, I'm sorry I type so much. I would rather type more than I need than say JUST enough, and have 5 people ask me wtf I'm going on about.
The first set of fake examples were to define categories. On each category line you would have a category name, a filter, and a list of arguments (such as dl/unrar dir). The filter argument could have either a single regexp/glob, or a null/- value. Since regexp support will be added for rss (presumably in the next version?), and be available to this feature if added you COULD merge numerous globs into a single regexp.
For people who's regexp-fu needs some additional meditation, I conceded that duplicate lines (same cat name) could be defined for multiple globs, or regexps per category. This might also have the added benefit for some people who have specific download directories for certain things... but would want the rest of the settings to be maintained across filters, such as people who download both xvid, as well as x264, but want both to be called one 'category'.
Each of these categories could hold numerous settings relatively easy, (see the example with the argument names being used in the second part) and I did not take the time to detail every possible setting, or name to be used. Hecks' original post had a couple suggestions that could be implemented into each category to overwrite defaults. The method I mocked together in the second part would not be TOO confusing to power-users who are used to command line arguments.
Once set up, a user would never look at it again for months+ at a time. I don't personally agree that this would be hard to set up at all. I CERTIANLY do not believe any categories should be pre-defined or autodetected by default. I am not sure if that was what you were implying, but just stating... I don't believe anything like that should be pre-configured during install.
Also, I believe you missed my first example for 'video.' That was a category definition, with no filter defined at all (notice the - implying to skip the argument). If this feature was implemented using the method I detailed in my suggestion... You would leave a generic example like that as a comment at the end of the default filter list, like the rss examples included during install. The user can then copy/paste it dozens of times very easily, substituting the names and directories as needed.
I also mentioned that a manual selection should be implemented in the download dialog for oddballs that do not match (or falsely match) existing filters. Similarly, this addition could be used by people who choose not to define any filters, yet do have categories listed.
The third set of examples was to show the use of a new (suggested) set of variables in the existing process. These variables would carry the values of whatever settings were included in the category config; perhaps user defined settings could be allowed as well (again, see the second section. The convention I used was '%CAT_{varname}'. The first example used in that section includes the parameter '%CAT_DL\tvshow\%NZBSUBJECT' which would be translated into 'c:\tv\tvshow\tv.show.s01...\' during rss download (which, as previously stated, is already implimented, other than the variable name %CAT_DL for download root).
PS This whole idea, COULD be implemented into a pref page, however it would take 10x longer to configure (no copy/paste, lots of retyping) AND it would make it slightly more 'dummy' proof. I don't believe dummyproofing usenet is the reason for this request, nor should it be a goal in general. This feature, just as the scripting, and rss features can be extremely powerful... they do not do ANYTHING without the user telling altbinz EXACTLY what to do or not to do; as should be for these types of features.
Anyway, hope this clears up what the examples meant. If not, lemme know what threw you.
