Congratulations. I don't know how I missed the announcement of 1.3.
Well, yes, actually, I do see. It didn't have a [net] in the title which is what my filter is looking for. Anyway, thanks for your hard work.
I'm not finished yet, but it really doesn't look hard, once you sink your teeth into it.
I think there work out to be three settable parameters:
1. SimpleDateFormat string for dates older than 1 year
2. SimpleDateFormat string for dates newer than 1 year
3. A delimited string of month abbreviations to replace the default ones with.
The regular expressions would see their current month/day/year/hour/minute groups replaced by
(\\S+\\s+\\S+\\s+\\S+)\\s+, creating a single string forwardable to the timestamp parser.
I have a nagging question about time zones. My suspicion is that there is no standard about of time zone usage under FTP and that the time zone in use on a particular server may not be automatically knowable to the user. This will come into play with files that are within +/- 24 hours of a year old. On the other hand, if our main use case is private FTP servers that the coder has reason to connect with rather than an all-purpose FTP tool, the time zone used is knowable to such a user and could also be a parameter, with perhaps GMT or the user's time zone used as a default (which?). The parameter would simply be one of the java.util.TimeZone ids, such as "America/New_York" or "GMT".
Aside from that, the more difficult issues are
1. packaging. Are we REPLACING the current parsers with localizable models or offering the localizable models as an alternative. My preference is for the former as the whole deprecation/removal business under Jakarta rules tends to be difficult. Much better to think this through beforehand than to have to undergo unnecessary deprecation later.
2. factory issues. This is really the key to the whole thing. What I absolutely don't want is a further combinatorial explosion of FTPClient.listFiles() methods. The factory methods for creating parsers would have to become the default methods. They would of course need sensible default values. They would fit well with clients such as Ant.
Steve
Rory Winston wrote:
Hi Steve,
I pushed out 1.3 in December - I think we agreed back then that the date formatting issue would be sufficiently large to necessitate waiting for a later release.
Coincidentally, I made a start at the extensible date parser as well, using a solution based on a SimpleDateFormat object. I would be very interested to see what you have come up with, so we can compare notes. I have kept the changes local as well, but maybe after we collaborate on this a little bit, we can start to patch into HEAD.
I'm stuck behind a narrowband connection for the next week or so, and will have only intermittet net access, but after next week I can get back into it again.
Cheers (and happy xmas), Rory
"Jakarta Commons Developers List" <commons-dev@jakarta.apache.org> wrote:
I finally have sufficient free time to begin implementing what we talked about in this conversation several months ago :
http://nagoya.apache.org/eyebrowse/SearchList?listId=&listName=commons-dev%40jakarta.apache.org&searchText=%22Designing+a+Date+Format-aware+FTP+Entry+Parser%22&defaultField=subject&Search=Search
How is the push to 1.3 release going? I don't want this release held up for this, as I still have little or no idea how long it will take to develop this implementation but neither do I want to interfere with it, so I may keep my implementation local for the time being.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
_________________________________________________________________ Sign up for eircom broadband now and get a free two month trial.* Phone 1850 73 00 73 or visit http://home.eircom.net/broadbandoffer
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
