>>What you are really saying is that the new code needs to have enough >>extension points that others could easily add new roll conditions. My >>concern is in how to provide that functionality and get renaming and >>deleting right. > >Since it's still our responsibility to rename files and the API just provides >only a "condition" and a "new file name" (or maybe even a set of new filenames?) >the code that renames (i.e. rolls) the file is still in the base implementation. Yes, but the renaming strategy becomes confused here. We have to know how that new roll condition is renamed. >
>So many pluses, I'm overwhelmed of the positive feedback! :-) I would stick with >the crond semantics here. They support these 5 cases: > >1) * matches every number >2) 5 matches exactly 5 >3) */5 matches everything with *%5 == 0, i.e. 0,5,10,15,20,25,.. >4) 5,7 matches for 5 or 7 >5) 5-7 matches 5,6 or 7 > >See here: http://adminschoice.com/crontab-quick-reference I will take a look at this. >>This brings me to File= parameter that has {Date} and {Size} etc. to >>indicate where date and size patterns are to be inserted. (Likewise >>for any other rolling condition.) If this idea is acceptable, then we >>do not have to worry about the date pattern separator or preserve >>extension etc. because it is all handled by the file pattern. The >>biggest downside that I see at this time is scanning the File= >>parameter to determine what goes where to create the directory search, >>but it should be doable without too much unfixable code. >> > >This will become tricky. Rolling by date and a unpredictable part in the filename >(like date) forces a algorithm candidate to search a set of files and therefore >the algorithm automatically degrades to something in between >O(n) and O(n^3). Rotating often a large amount of backups can devastate the >performance. So maybe we'll have to distinguish two rolling strategies and never >mix them: I have already written code that could parse the old datepattern and determine where ? needed to go to do the file directory search. That code or a close relative can survive into the new model so, the directory search is still just a single pass with a mask. I even fixed that mask to take into account the size roll increment number also, which is why I wanted to make fixed width. I really think we need to provide for multiple name parts as proposed above. I think I should be able to keep the performance acceptable.
