Re: [net] 1.2 release (Re: [net] checked in parser factory implementation)
On Friday 09 January 2004 03:22 am, Daniel F. Savarese wrote: > In message <[EMAIL PROTECTED]>, steve cohen writes: > >I also agree that there is a need for postfiltering (to solve the "most > > recent version only" problem), although, actually, I think prefiltering > > out the dupes may be the way to go. Either way, some kind of hook will > > be necessary, one that's a no-op in the default case. If time gets to be > > a factor we can leave this as a known issue for later. No one's actually > > complained about it other than me, from reading the code. > > I went ahead and made the changes I had put out for discussion (see > comments in CVS commit log). It seemed easier to make them and let you > improve on them or revert them. There should be no impact on existing > code. However, I had to introduce createFTPFileList into the > FTPFileEntryParser interface. I don't like the name of this method. It's > basically an FTPFileList version of parserFileList. If we keep this > change, we should ome up with a more appropriate name. I'll take a look at it. > > There are some things I didn't understand in FTPFileListIterator (now > an abstract class with DefaultFTPFileListIterator containing the > implementation code). Is getNext(0) supposed to return all remaining > elements and getPrevious(0) all elements between 0 and the current > position? Yes. I had to look at the code but that's what the code does and the javadocs indicate the same. > Also, FTPFileList.getFiles() (now DefaultFTPFileList.getFiles() > with FTPFileList being an abstract class) was returning > iterator().getNext(0). I changed this to iterator().getFiles(), which was > less confusing to me. But it seems that getFiles() actually does something > different than getNext(0), reinitializing the current position. Is there > something that needs to be fixed there? I didn't want to change anything > there. Good catch. This was a flaw and you fixed it. getFiles() gets the complete list. getNext(0) gets the rest, which is the same only if done from the beginning. > Please doublecheck VMSFTPEntryParser.DuplicateFilteringIterator to > ensure it implements the getNext() and getPrevious() methods as > intended. I included little comments saying how I interpreted the 0 > argument. > > I didn't fix up all affected javadocs (too late, too tired). I also > didn't split out VMSFTPEntryParser into two classes, but that should > be easy for anyone else to do. Basically, all I did was shuffle code > around to make user customization easier. The only new code I wrote > were a couple of methods in DuplicateFilteringIterator, but it really > just grafts part of the old parseFileList which is now split between > DuplicateFilteringIterator and createFTPFileList(). I'll take it from here. I should be in good shape by the end of the weekend. I'm putting a new computer system together today. > > - > 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]
Re: [net] 1.2 release (Re: [net] checked in parser factory implementation)
In message <[EMAIL PROTECTED]>, steve cohen writes: >I also agree that there is a need for postfiltering (to solve the "most recent >version only" problem), although, actually, I think prefiltering out the >dupes may be the way to go. Either way, some kind of hook will be necessary, >one that's a no-op in the default case. If time gets to be a factor we can >leave this as a known issue for later. No one's actually complained about it >other than me, from reading the code. I went ahead and made the changes I had put out for discussion (see comments in CVS commit log). It seemed easier to make them and let you improve on them or revert them. There should be no impact on existing code. However, I had to introduce createFTPFileList into the FTPFileEntryParser interface. I don't like the name of this method. It's basically an FTPFileList version of parserFileList. If we keep this change, we should ome up with a more appropriate name. There are some things I didn't understand in FTPFileListIterator (now an abstract class with DefaultFTPFileListIterator containing the implementation code). Is getNext(0) supposed to return all remaining elements and getPrevious(0) all elements between 0 and the current position? Also, FTPFileList.getFiles() (now DefaultFTPFileList.getFiles() with FTPFileList being an abstract class) was returning iterator().getNext(0). I changed this to iterator().getFiles(), which was less confusing to me. But it seems that getFiles() actually does something different than getNext(0), reinitializing the current position. Is there something that needs to be fixed there? I didn't want to change anything there. Please doublecheck VMSFTPEntryParser.DuplicateFilteringIterator to ensure it implements the getNext() and getPrevious() methods as intended. I included little comments saying how I interpreted the 0 argument. I didn't fix up all affected javadocs (too late, too tired). I also didn't split out VMSFTPEntryParser into two classes, but that should be easy for anyone else to do. Basically, all I did was shuffle code around to make user customization easier. The only new code I wrote were a couple of methods in DuplicateFilteringIterator, but it really just grafts part of the old parseFileList which is now split between DuplicateFilteringIterator and createFTPFileList(). daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] 1.2 release (Re: [net] checked in parser factory implementation)
> On Thu, 08 Jan 2004 17:38:50 -0500, "Daniel F. Savarese" <[EMAIL PROTECTED]> > said: [SNIPPED] > In other news, we need to write a status file to keep track of what > we need to get done before a 1.2 release. I'll get to it over the > next week if no one beats me to it. So far we've got the VMS parser > issue and a review of the NTP/SNTP code. We ought to scan the bug > list, but if Ant is waiting for a new release, we can postpone bug > fixes to 1.2.1 and make 1.2 only a functionality enhancement > release. I just threw them into the to-do list and pushed out a new version of the http://jakarta.apache.org/commons/net/ site. Feel free to add/update/delete whatever and I can roll the site if need be. -- = Jeffrey D. Brekke [EMAIL PROTECTED] Wisconsin, USA [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] 1.2 release (Re: [net] checked in parser factory implementation)
In message <[EMAIL PROTECTED]>, "Noel J. Bergman" w rites: >> We may need a signed CLA before we can include it should it pass muster. > >This is an area I find confusing, as well, but AIUI to date we mostly >require a CLA only from a committer. If the codebase is significant (a grey >area), one could ask for a software grant, as we have done in some cases. I should have said software grant. That is, unless we vote Jason Matthews in as a committer (or already is one unbeknownst to me), which we will probably want to do if he's committed to helping maintain the code. At any rate, after reviewing the code, should we decide to assimilate it, we ought to fire an inquiry to the PMC list since it's more than a small patch. My preference is to get something signed whether it's a software grant or the usual mandatory CLA after voting the contributor in as a committer. In other news, we need to write a status file to keep track of what we need to get done before a 1.2 release. I'll get to it over the next week if no one beats me to it. So far we've got the VMS parser issue and a review of the NTP/SNTP code. We ought to scan the bug list, but if Ant is waiting for a new release, we can postpone bug fixes to 1.2.1 and make 1.2 only a functionality enhancement release. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] 1.2 release (Re: [net] checked in parser factory implementation)
+1 to subclassing and agreement ;) > On Wed, 07 Jan 2004 13:38:27 -0600, steve cohen <[EMAIL PROTECTED]> said: [SNIPPED] > On Wednesday 07 January 2004 11:44 am, Daniel F. Savarese wrote: >> In message <[EMAIL PROTECTED]>, Jeffrey D. Brekke writes: >> >[Alternatives to VMS Parser/Version issue] >> > >> >Another alternative is to create another parser, creating two VMS >> >parsers, potentially sub-classing one VMS parser to avoid code >> >duplication. A specialized VMS parser that will filter off >> multiple >versions. This solves the contract problems with the >> parsers and >> >> I was about to say "Eureka!, that's the right solution." as far as >> the specific VMS parser case goes, but there's still the problem of >> how to make it filter off multiple versions when called using >> readNextEntry and parseFTPEntry. Unless I'm missing something, we >> still have to support some hook for the postfiltering. >> Nonetheless, splitting the VMS parsing functionality into two >> separate classes (one derived from the other) is cleaner than using >> the versioning property. > I think we're all in agreement here. The subclass is cleanest the > way to go. (See, Jeffrey, that wasn't so hard). [SNIPPED] -- = Jeffrey D. Brekke [EMAIL PROTECTED] Wisconsin, USA [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] 1.2 release (Re: [net] checked in parser factory implementation)
On Wednesday 07 January 2004 11:44 am, Daniel F. Savarese wrote: > In message <[EMAIL PROTECTED]>, Jeffrey D. Brekke writes: > >[Alternatives to VMS Parser/Version issue] > > > >Another alternative is to create another parser, creating two VMS > >parsers, potentially sub-classing one VMS parser to avoid code > >duplication. A specialized VMS parser that will filter off multiple > >versions. This solves the contract problems with the parsers and > > I was about to say "Eureka!, that's the right solution." as far > as the specific VMS parser case goes, but there's still the problem > of how to make it filter off multiple versions when called using > readNextEntry and parseFTPEntry. Unless I'm missing something, > we still have to support some hook for the postfiltering. Nonetheless, > splitting the VMS parsing functionality into two separate classes > (one derived from the other) is cleaner than using the versioning > property. I think we're all in agreement here. The subclass is cleanest the way to go. (See, Jeffrey, that wasn't so hard). I also agree that there is a need for postfiltering (to solve the "most recent version only" problem), although, actually, I think prefiltering out the dupes may be the way to go. Either way, some kind of hook will be necessary, one that's a no-op in the default case. If time gets to be a factor we can leave this as a known issue for later. No one's actually complained about it other than me, from reading the code. > > >[FTPClient API coherence] > > > >On the point of the FTPClient api, I was under the impression also > >that we were leaning toward a FTPFileList as the norm, and away from > >the arrays. Maybe now that we're 1.2 bound, we can just return List > >and have FTPFileList implement the List interface ( and Iterator > >interface, opening up the possibility of using commons/collections > >filter iterator or other collection utilities )? > > I see Steven and you have made further comments in the thread about > this. I'm in favor of whatever provides sufficient flexibility so > that API users can customize behavior without requiring us to > shoehorn application-specific functionality into the library. > I'm not sure about having FTPFileList implement List, or perhaps > Collection, but I haven't sorted out my thoughts. There could > be considerable advantages. Also, one of the possibilities I > threw out was having void listFiles(FTPFileList, ...), where the > results are returned in the FTPFileList, which would require at > least clear() and possibly add() methods depending on the > implementation. > > >I guess we're spiraling out of control here with ideas ( not > >necessarily a bad thing ). Just not sure how to rein us in ;) > > Although I don't want to put off decisions, we can always take > a baby step to resolve the immediate VMS entry parser issue and > take some more time to figure out the rest. That is, unless > they are inextricably tied ... We've got several options for > allowing ant to grab a VMS entry parser with version filtering. > I think we've agreed that splitting out the functionality into > a subclass is the way to go. But we still need a way to implement > the version filtering transparently without depending on parseFileList. > > daniel > > Frankly I think we could have this coded by the weekend if not sooner. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] 1.2 release (Re: [net] checked in parser factory implementation)
On Wednesday 07 January 2004 11:14 am, Daniel F. Savarese wrote: > In message <[EMAIL PROTECTED]>, steve cohen writes: > >I keep coming back to the ant use case and how we'd handle it there. I > >suppose we could add yet another parameter to the ant task to handle > >this odd case, but I'd rather not. I'm still not happy with this but I > > don't have a better suggestion yet. > > Okay, so am I correct that in ant you can explictly define the parser key? > If that's the case then one can implement a factory that recognizes a > special parser key (or add it to the default factory), like VMSV that > will create a VMS entry parser which handles versioning. That is, assuming > the ant task calls listFiles(String, String), which is what I understood > to be the reason you gave to keep the method public when Jeffrey suggested > it not be public. > > daniel > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] Exactly so. This will work. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [net] 1.2 release (Re: [net] checked in parser factory implementation)
Daniel F. Savarese wrote: > I also forgot to add that there's at least one pending code submission/patch > that we need to review and include before a 1.2 release. I believe it was > the NTP/SNTP functionality submitted by Jason Matthews. Correct. On September 14, and corrected on October 8. http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED] he.org&msgNo=33993 http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED] he.org&msgNo=35816 > We may need a signed CLA before we can include it should it pass muster. This is an area I find confusing, as well, but AIUI to date we mostly require a CLA only from a committer. If the codebase is significant (a grey area), one could ask for a software grant, as we have done in some cases. The revised ASF licenses are supposed to help clear up questions related to contributions. But Jason did post it to the mailing list for the specific purpose of having it incorporated, and he applied the ASF License to each file. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] 1.2 release (Re: [net] checked in parser factory implementation)
In message <[EMAIL PROTECTED]>, Jeffrey D. Brekke writes: >[Alternatives to VMS Parser/Version issue] > >Another alternative is to create another parser, creating two VMS >parsers, potentially sub-classing one VMS parser to avoid code >duplication. A specialized VMS parser that will filter off multiple >versions. This solves the contract problems with the parsers and I was about to say "Eureka!, that's the right solution." as far as the specific VMS parser case goes, but there's still the problem of how to make it filter off multiple versions when called using readNextEntry and parseFTPEntry. Unless I'm missing something, we still have to support some hook for the postfiltering. Nonetheless, splitting the VMS parsing functionality into two separate classes (one derived from the other) is cleaner than using the versioning property. >[FTPClient API coherence] > >On the point of the FTPClient api, I was under the impression also >that we were leaning toward a FTPFileList as the norm, and away from >the arrays. Maybe now that we're 1.2 bound, we can just return List >and have FTPFileList implement the List interface ( and Iterator >interface, opening up the possibility of using commons/collections >filter iterator or other collection utilities )? I see Steven and you have made further comments in the thread about this. I'm in favor of whatever provides sufficient flexibility so that API users can customize behavior without requiring us to shoehorn application-specific functionality into the library. I'm not sure about having FTPFileList implement List, or perhaps Collection, but I haven't sorted out my thoughts. There could be considerable advantages. Also, one of the possibilities I threw out was having void listFiles(FTPFileList, ...), where the results are returned in the FTPFileList, which would require at least clear() and possibly add() methods depending on the implementation. >I guess we're spiraling out of control here with ideas ( not >necessarily a bad thing ). Just not sure how to rein us in ;) Although I don't want to put off decisions, we can always take a baby step to resolve the immediate VMS entry parser issue and take some more time to figure out the rest. That is, unless they are inextricably tied ... We've got several options for allowing ant to grab a VMS entry parser with version filtering. I think we've agreed that splitting out the functionality into a subclass is the way to go. But we still need a way to implement the version filtering transparently without depending on parseFileList. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] 1.2 release (Re: [net] checked in parser factory implementation)
In message <[EMAIL PROTECTED]>, steve cohen writes: >I keep coming back to the ant use case and how we'd handle it there. I >suppose we could add yet another parameter to the ant task to handle >this odd case, but I'd rather not. I'm still not happy with this but I don't >have a better suggestion yet. Okay, so am I correct that in ant you can explictly define the parser key? If that's the case then one can implement a factory that recognizes a special parser key (or add it to the default factory), like VMSV that will create a VMS entry parser which handles versioning. That is, assuming the ant task calls listFiles(String, String), which is what I understood to be the reason you gave to keep the method public when Jeffrey suggested it not be public. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] 1.2 release (Re: [net] checked in parser factory implementation)
> On Wed, 07 Jan 2004 05:44:36 -0600, steve cohen <[EMAIL PROTECTED]> said:
> On Tuesday 06 January 2004 11:04 pm, Jeffrey D. Brekke wrote:
>> Steve/Daniel,
>>
>> I'm responding to snippets from several messages in this one
>> message, sorry if it's confusing...
>>
>> [Iterator idea]
>>
>> When I suggested the filtering iterator I was thinking of something
>> really simple, like an additional class or example of how one could
>> filter off multiple versions when iterating and leaving the VMS
>> parser simple, just parsing the list with versions intact.
> This sounds interesting but I don't really understand how it would
> work. Do you have some example from some other system in mind?
[SNIPPED]
No, but I was just thinking that we'd use Commons/Collections
FilterIterator or some such and provide either the implementation or
an example of how one could do it. A FilterIterator that would
basically just suppress multiple versions.
I haven't done any more than look into javadoc really. If I get time
I'll try it out.
>> [Alternatives to VMS Parser/Version issue]
>>
>> Another alternative is to create another parser, creating two VMS
>> parsers, potentially sub-classing one VMS parser to avoid code
>> duplication. A specialized VMS parser that will filter off
>> multiple versions. This solves the contract problems with the
>> parsers and keeps the classes following SRP. If someone doesn't
>> like the VMS parser our factory defaults to for auto-detection (
>> we'll have to decide on one of them ), they could write their own
>> factory ( or we could write a property-backed factory for easy
>> customization or something ).
> I was thinking along these lines too. I didn't pursue it because it
> seemed ugly, but is it? I'm not so sure it is. VMS with versioning
> is really a very significant difference from VMS without versioning,
> and yet similar enough that the IS-A relation is a good fit. It's
> certainly easier to do this than to do what Daniel and I were
> talking about, and it's conceptually defensible too. We don't need
> to change the factory for this either - just like the Enhanced Unix,
> this one wouldn't be available to auto-detection, but accessible via
> key or classname and manual coding.
>> [FTPClient API coherence]
>>
>> On the point of the FTPClient api, I was under the impression also
>> that we were leaning toward a FTPFileList as the norm, and away
>> from the arrays. Maybe now that we're 1.2 bound, we can just
>> return List and have FTPFileList implement the List interface ( and
>> Iterator interface, opening up the possibility of using
>> commons/collections filter iterator or other collection utilities
>> )?
> I'm not sure I agree here. FTPFileList (despite its name) is not a
> list of FTPFiles. It is a wrapper around vector of raw FTP entries
> designed to implement Daniel's old suggestion that a quick read of
> the list be separated in time from the creation of more expensive
> FTPFile objects, which would be created as needed when iterating the
> list in a paged fashion, or possibly by a different thread.
> This is not to say that there might not be a good reason to make
> listFiles() methods return Lists instead of arrays, but that's
> different from FTPFileList.
>> I guess we're spiraling out of control here with ideas ( not
>> necessarily a bad thing ). Just not sure how to rein us in ;)
> If we're still at this point by next week, then you should worry.
> :-)
>> > On Tue, 06 Jan 2004 19:47:15 -0600, steve cohen >
>> <[EMAIL PROTECTED]> said:
>> >
>> > On Tuesday 06 January 2004 07:08 pm, Daniel F. Savarese wrote:
>> >> In message <[EMAIL PROTECTED]>, steve
>> cohen >> writes: >Almost right, Daniel. I think it filters out
>> dupes when >> versioning is > turned on.
>> >>
>> >> I thought that's what you said before, but I saw if (versioning)
>> { >> files = super.parseFileList(listingStream); } else { in >>
>> VMSFTPEntryParser.parseFileList. Is that an error? Should it be
>> >> if (!versioning) or do I have the meaning of the versioning >>
>> variable mixed up? Just wondering if we found a bug.
>> >
>> > You're right. I'm sorry. You read what the code said. I "read"
>> > what I thought the code should be saying. It does seem >
>> counter-intuitive the way it is, but maybe there's a way to >
>> understand it that I don't have, by which it makes sense. I've >
>> explicitly added Stephane Este-Gracias (who wrote this code) to
>> this > thread for his opinion. Stephane, if you see this, please
>> weigh in > on this.
>> >
>> >> >Actually, I like your suggestion. The iterator seems the right
>> >>
>> >> place to > do it.
>> >>
>> >> As you know by now from my subsequent email, I have yet another
>> >> suggestion :)
>> >
>> > Which I've already responded to so will say no more here.
>> >
>> >> >Here's another problem, though, in our system. How do you turn
>> >>
>> >> versioning > on in the auto-detect scenario? There's no hook in
>> >>
Re: [net] 1.2 release (Re: [net] checked in parser factory implementation)
On Tuesday 06 January 2004 11:04 pm, Jeffrey D. Brekke wrote:
> Steve/Daniel,
>
> I'm responding to snippets from several messages in this one message,
> sorry if it's confusing...
>
> [Iterator idea]
>
> When I suggested the filtering iterator I was thinking of something
> really simple, like an additional class or example of how one could
> filter off multiple versions when iterating and leaving the VMS parser
> simple, just parsing the list with versions intact.
This sounds interesting but I don't really understand how it would work. Do
you have some example from some other system in mind?
>
> [Alternatives to VMS Parser/Version issue]
>
> Another alternative is to create another parser, creating two VMS
> parsers, potentially sub-classing one VMS parser to avoid code
> duplication. A specialized VMS parser that will filter off multiple
> versions. This solves the contract problems with the parsers and
> keeps the classes following SRP. If someone doesn't like the VMS parser
> our factory defaults to for auto-detection ( we'll have to decide on
> one of them ), they could write their own factory ( or we could write
> a property-backed factory for easy customization or something ).
I was thinking along these lines too. I didn't pursue it because it seemed
ugly, but is it? I'm not so sure it is. VMS with versioning is really a
very significant difference from VMS without versioning, and yet similar
enough that the IS-A relation is a good fit. It's certainly easier to do
this than to do what Daniel and I were talking about, and it's conceptually
defensible too. We don't need to change the factory for this either - just
like the Enhanced Unix, this one wouldn't be available to auto-detection, but
accessible via key or classname and manual coding.
>
> [FTPClient API coherence]
>
> On the point of the FTPClient api, I was under the impression also
> that we were leaning toward a FTPFileList as the norm, and away from
> the arrays. Maybe now that we're 1.2 bound, we can just return List
> and have FTPFileList implement the List interface ( and Iterator
> interface, opening up the possibility of using commons/collections
> filter iterator or other collection utilities )?
I'm not sure I agree here. FTPFileList (despite its name) is not a list of
FTPFiles. It is a wrapper around vector of raw FTP entries designed to
implement Daniel's old suggestion that a quick read of the list be separated
in time from the creation of more expensive FTPFile objects, which would be
created as needed when iterating the list in a paged fashion, or possibly by
a different thread.
This is not to say that there might not be a good reason to make listFiles()
methods return Lists instead of arrays, but that's different from
FTPFileList.
>
> I guess we're spiraling out of control here with ideas ( not
> necessarily a bad thing ). Just not sure how to rein us in ;)
If we're still at this point by next week, then you should worry.
:-)
>
> > On Tue, 06 Jan 2004 19:47:15 -0600, steve cohen
> > <[EMAIL PROTECTED]> said:
> >
> > On Tuesday 06 January 2004 07:08 pm, Daniel F. Savarese wrote:
> >> In message <[EMAIL PROTECTED]>, steve cohen
> >> writes: >Almost right, Daniel. I think it filters out dupes when
> >> versioning is > turned on.
> >>
> >> I thought that's what you said before, but I saw if (versioning) {
> >> files = super.parseFileList(listingStream); } else { in
> >> VMSFTPEntryParser.parseFileList. Is that an error? Should it be
> >> if (!versioning) or do I have the meaning of the versioning
> >> variable mixed up? Just wondering if we found a bug.
> >
> > You're right. I'm sorry. You read what the code said. I "read"
> > what I thought the code should be saying. It does seem
> > counter-intuitive the way it is, but maybe there's a way to
> > understand it that I don't have, by which it makes sense. I've
> > explicitly added Stephane Este-Gracias (who wrote this code) to this
> > thread for his opinion. Stephane, if you see this, please weigh in
> > on this.
> >
> >> >Actually, I like your suggestion. The iterator seems the right
> >>
> >> place to > do it.
> >>
> >> As you know by now from my subsequent email, I have yet another
> >> suggestion :)
> >
> > Which I've already responded to so will say no more here.
> >
> >> >Here's another problem, though, in our system. How do you turn
> >>
> >> versioning > on in the auto-detect scenario? There's no hook in
> >> listFiles() for doing > so.
> >>
> >> I would say that's where the FTPFileEntryParserFactory comes in.
> >> If someone wants VMSFTPEntryParsers with versioning turned on, they
> >> can implement a factory that returns them. We could add a
> >> setVMSVersioning(boolean) method to
> >> DefaultFTPFileEntryParserFactory and save users the trouble.
> >> They'd have to do the following: FTPClient ftp = new FTPClient();
> >> DefaultFTPFileEntryParserFactory factory = new
> >> DefaultFTPFileEntryParserFactory(); factory.s
Re: [net] 1.2 release (Re: [net] checked in parser factory implementation)
Steve/Daniel,
I'm responding to snippets from several messages in this one message,
sorry if it's confusing...
[Iterator idea]
When I suggested the filtering iterator I was thinking of something
really simple, like an additional class or example of how one could
filter off multiple versions when iterating and leaving the VMS parser
simple, just parsing the list with versions intact.
[Alternatives to VMS Parser/Version issue]
Another alternative is to create another parser, creating two VMS
parsers, potentially sub-classing one VMS parser to avoid code
duplication. A specialized VMS parser that will filter off multiple
versions. This solves the contract problems with the parsers and
keeps the classes following SRP. If someone doesn't like the VMS parser
our factory defaults to for auto-detection ( we'll have to decide on
one of them ), they could write their own factory ( or we could write
a property-backed factory for easy customization or something ).
[FTPClient API coherence]
On the point of the FTPClient api, I was under the impression also
that we were leaning toward a FTPFileList as the norm, and away from
the arrays. Maybe now that we're 1.2 bound, we can just return List
and have FTPFileList implement the List interface ( and Iterator
interface, opening up the possibility of using commons/collections
filter iterator or other collection utilities )?
I guess we're spiraling out of control here with ideas ( not
necessarily a bad thing ). Just not sure how to rein us in ;)
> On Tue, 06 Jan 2004 19:47:15 -0600, steve cohen <[EMAIL PROTECTED]> said:
> On Tuesday 06 January 2004 07:08 pm, Daniel F. Savarese wrote:
>> In message <[EMAIL PROTECTED]>, steve cohen
>> writes: >Almost right, Daniel. I think it filters out dupes when
>> versioning is > turned on.
>>
>> I thought that's what you said before, but I saw if (versioning) {
>> files = super.parseFileList(listingStream); } else { in
>> VMSFTPEntryParser.parseFileList. Is that an error? Should it be
>> if (!versioning) or do I have the meaning of the versioning
>> variable mixed up? Just wondering if we found a bug.
> You're right. I'm sorry. You read what the code said. I "read"
> what I thought the code should be saying. It does seem
> counter-intuitive the way it is, but maybe there's a way to
> understand it that I don't have, by which it makes sense. I've
> explicitly added Stephane Este-Gracias (who wrote this code) to this
> thread for his opinion. Stephane, if you see this, please weigh in
> on this.
>> >Actually, I like your suggestion. The iterator seems the right
>> place to > do it.
>>
>> As you know by now from my subsequent email, I have yet another
>> suggestion :)
> Which I've already responded to so will say no more here.
>> >Here's another problem, though, in our system. How do you turn
>> versioning > on in the auto-detect scenario? There's no hook in
>> listFiles() for doing > so.
>>
>> I would say that's where the FTPFileEntryParserFactory comes in.
>> If someone wants VMSFTPEntryParsers with versioning turned on, they
>> can implement a factory that returns them. We could add a
>> setVMSVersioning(boolean) method to
>> DefaultFTPFileEntryParserFactory and save users the trouble.
>> They'd have to do the following: FTPClient ftp = new FTPClient();
>> DefaultFTPFileEntryParserFactory factory = new
>> DefaultFTPFileEntryParserFactory(); factory.setVMSVersioning(true);
>> ftp.setParserFactory(factory);
>>
>> Does that sound acceptable or is there a better way?
> I keep coming back to the ant use case and how we'd handle it there.
> I suppose we could add yet another parameter to the ant task
> to handle this odd case, but I'd rather not. I'm still not happy
> with this but I don't have a better suggestion yet.
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--
=
Jeffrey D. Brekke [EMAIL PROTECTED]
Wisconsin, USA [EMAIL PROTECTED]
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] 1.2 release (Re: [net] checked in parser factory implementation)
On Tuesday 06 January 2004 07:08 pm, Daniel F. Savarese wrote:
> In message <[EMAIL PROTECTED]>, steve cohen writes:
> >Almost right, Daniel. I think it filters out dupes when versioning is
> > turned on.
>
> I thought that's what you said before, but I saw
> if (versioning) {
> files = super.parseFileList(listingStream);
> } else {
> in VMSFTPEntryParser.parseFileList. Is that an error? Should it
> be if (!versioning) or do I have the meaning of the versioning
> variable mixed up? Just wondering if we found a bug.
You're right. I'm sorry. You read what the code said. I "read" what I
thought the code should be saying. It does seem counter-intuitive the way it
is, but maybe there's a way to understand it that I don't have, by which it
makes sense. I've explicitly added Stephane Este-Gracias (who wrote this
code) to this thread for his opinion. Stephane, if you see this, please
weigh in on this.
>
> >Actually, I like your suggestion. The iterator seems the right place to
> > do it.
>
> As you know by now from my subsequent email, I have yet another suggestion
> :)
Which I've already responded to so will say no more here.
>
> >Here's another problem, though, in our system. How do you turn versioning
> > on in the auto-detect scenario? There's no hook in listFiles() for doing
> > so.
>
> I would say that's where the FTPFileEntryParserFactory comes in. If
> someone wants VMSFTPEntryParsers with versioning turned on, they
> can implement a factory that returns them. We could add a
> setVMSVersioning(boolean) method to DefaultFTPFileEntryParserFactory
> and save users the trouble. They'd have to do the following:
> FTPClient ftp = new FTPClient();
> DefaultFTPFileEntryParserFactory factory =
> new DefaultFTPFileEntryParserFactory();
> factory.setVMSVersioning(true);
> ftp.setParserFactory(factory);
>
> Does that sound acceptable or is there a better way?
I keep coming back to the ant use case and how we'd handle it there. I
suppose we could add yet another parameter to the ant task to handle
this odd case, but I'd rather not. I'm still not happy with this but I don't
have a better suggestion yet.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] 1.2 release (Re: [net] checked in parser factory implementation)
In message <[EMAIL PROTECTED]>, steve cohen writes:
>Almost right, Daniel. I think it filters out dupes when versioning is turned
>on.
I thought that's what you said before, but I saw
if (versioning) {
files = super.parseFileList(listingStream);
} else {
in VMSFTPEntryParser.parseFileList. Is that an error? Should it
be if (!versioning) or do I have the meaning of the versioning
variable mixed up? Just wondering if we found a bug.
>Actually, I like your suggestion. The iterator seems the right place to do
>it.
As you know by now from my subsequent email, I have yet another suggestion :)
>Here's another problem, though, in our system. How do you turn versioning on
>in the auto-detect scenario? There's no hook in listFiles() for doing so.
I would say that's where the FTPFileEntryParserFactory comes in. If
someone wants VMSFTPEntryParsers with versioning turned on, they
can implement a factory that returns them. We could add a
setVMSVersioning(boolean) method to DefaultFTPFileEntryParserFactory
and save users the trouble. They'd have to do the following:
FTPClient ftp = new FTPClient();
DefaultFTPFileEntryParserFactory factory =
new DefaultFTPFileEntryParserFactory();
factory.setVMSVersioning(true);
ftp.setParserFactory(factory);
Does that sound acceptable or is there a better way?
daniel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] 1.2 release (Re: [net] checked in parser factory implementation)
On Tuesday 06 January 2004 05:53 pm, Daniel F. Savarese wrote: > > I think FTPFileEntryParser is the key to customization. All of our > problems would be solved if instead of a static FTPFileList.create > method, there were a per-instance FTPFileList createFileList method > in FTPFileEntryParser. Although, in that case it would help for > FTPFileList to be an interface. Since FTPFileList has a private > constructor and API users can only create instances with create(), > maybe we can make FTPFileList an abstract class without breaking > anything and move the current implementation into a subclass. > FTPClient would use the parser createFileList method and VMSFileEntryParser > would return an FTPFileList subclass that did the right thing, either > by producing a filtering iterator derived from FTPFileIterator or by > redefining the way the stream is read. I'm not saying this is the best > way to go, but it does offer more flexibility than either of our previous > suggestions without breaking anything. At any rate, it's another idea to > throw into the pot. Let's brainstorm some more and make a list of pros > and cons. > > daniel I like where you're going here. You are untying knots. This is good. If we polymorphize file list creation and let the parser dictate which type it creates, that would get us where we want to go and put the solution in the right place. Possibly there might need to be a polymorphic iterator too. Something like DupeRemovingFTPFileIterator. Also, I'm not sure we're doing the right thing now anyway. What we're doing doesn't guarantee getting the most recent version. The way it currently works is the last version encountered is used. But does anything guarantee that the listing comes out in version order? I don't know anything about VMS but no other OS I know makes such a guarantee. If I'm right, then instead of doing a simple Hashtable.put() we need to do a get() first, and then put() only if get() returned null or if the new FTPFile has a higher version number than the one retrieved. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] 1.2 release (Re: [net] checked in parser factory implementation)
In message <[EMAIL PROTECTED]>, steve cohen writes: >After looking at the code, I have a different idea. Reimplementing >createFileList() in terms of parseFileList() would negate the whole reason >for inventing createFileList() in the first place - your suggestion wishing Agreed. I'm lagging behind the discussions because of the digest, so I said some stupid things :) >VMSFileEntryParser.parseFTPEntry(). A duplicate entry could return null or >else a special value (public static final FTPFile DUPLICATE_ENTRY = new >FTPFile();). FTPFileIterator would skip all such instances. The only other >thing needed would be a new method in FTPFileEntryParser to reinitialize this >cache. The default implementation of this in FTPFileEntryParserImpl would be >a no-op but the VMS case there would actually be a cache to empty. I also considered that VMSFileEntryParser could manage the removal of duplicates itself, except I saw the need to demarcate the start (and possibly stop) of a listing as a showstopper. It seemed like a special case just for VMSFileEntryParser, in the same way the createIterator idea I suggested seems. I think what we have to discover is the most appropriate general case that encompasses the situation we face with VMSFileEntryParser. If we build special support into FTPFileIterator for handling duplicates, we don't gain any additional flexibility. That's why I favor a way of implementing Jeffrey's iterator filter/adapter idea with as little impact to existing code as possible. It gives additional flexibilty. However, that doesn't mean we don't also need a way to allow entry parsers to maintain state while the parsing of a file listing is in progress. Whether that should be done by adding a new method (indicating the start of a listing; where the cache could be initialized) or an extra parameters to parseFTPEntry (e.g., an integer indicating the number of the entry; 0 indicates the first entry) I don't know. A startListing() or similar method is probably the more flexible approach if we decide that's necessary. I'm of the mind we've run into an architectural weakness and have to rethink how FTPFileList, FTPFileIterator, FTPFileEntryParser, and FTPClient should interact. Right now, we don't have a clear path for extending/customizing FTPFileList and FTPFileIterator behavior as it relates to FTPFileEntryParser instances. Granted, we have only this one case with VMSFileEntryParser to consider, but there may be others lurking around the corner we need to anticipate. I think FTPFileEntryParser is the key to customization. All of our problems would be solved if instead of a static FTPFileList.create method, there were a per-instance FTPFileList createFileList method in FTPFileEntryParser. Although, in that case it would help for FTPFileList to be an interface. Since FTPFileList has a private constructor and API users can only create instances with create(), maybe we can make FTPFileList an abstract class without breaking anything and move the current implementation into a subclass. FTPClient would use the parser createFileList method and VMSFileEntryParser would return an FTPFileList subclass that did the right thing, either by producing a filtering iterator derived from FTPFileIterator or by redefining the way the stream is read. I'm not saying this is the best way to go, but it does offer more flexibility than either of our previous suggestions without breaking anything. At any rate, it's another idea to throw into the pot. Let's brainstorm some more and make a list of pros and cons. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] 1.2 release (Re: [net] checked in parser factory implementation)
On Tuesday 06 January 2004 12:40 pm, Daniel F. Savarese wrote: > In message <[EMAIL PROTECTED]>, steve cohen writes: > >There's still one problem with deprecating FTPFileListParser. > >The one method of this interface (parseFileList()) is used in the > >VMSFTPEntryParser. There is an implementation here that is distinct from > > the default one in FTPFileListParserImpl. > > ... > > >If we still want to deprecate FTPFileListParser, I would recommend, then, > > that > > > >we move parseFileList() into the FTPFileEntryParser interface. However, I > >wanted to throw this question out there for general comment before I do > > that. > > In one of my emails I started writing "I'm not entirely convinced we need > to deprecate FTPFileListParser ..." but I couldn't really support that > so I deleted that thought. You nailed the case where it makes a > difference. The question remains though, how do we support this when the > only way parseFileList is called is in listFiles(FTPFileListParser, ...), > which we're deprecating and going to remove? I don't think we want the API > user to have to be intimate with the different parsers and figure out when > to call listFiles(FTPFileListParser, ...) and when not to. Moving > parseFileList into FTPFileEntryParser won't solve the problem unless we > make parseFileList the single entry point to creating file lists from > FTPClient (since all of the FTPFileEntryParser implementations we have so > far implement parseFileList). > > Looking at the code, I would have to agree that parseFileList should > be preserved and move into FTPFileEntryParser. That allows us to > rewrite createFileList to call parseFileList instead of > FTPFileList.create, which allows the VMSFTPEntryParser to continue > doing its thing. > > daniel > After looking at the code, I have a different idea. Reimplementing createFileList() in terms of parseFileList() would negate the whole reason for inventing createFileList() in the first place - your suggestion wishing for a way to postpone the creation of expensive FileList objects until needed. I think the solution should rest within the FTPFileEntryParser concept as implemented by the VMSFileEntryParser. That parser, when working with a versioning system, should maintain its cache of existing entries and not return duplicates. This is similar to what VMSFileEntryParser.parseFileList() does now, except that the cache is a class member and not a local variable. The best place to implement this is in VMSFileEntryParser.parseFTPEntry(). A duplicate entry could return null or else a special value (public static final FTPFile DUPLICATE_ENTRY = new FTPFile();). FTPFileIterator would skip all such instances. The only other thing needed would be a new method in FTPFileEntryParser to reinitialize this cache. The default implementation of this in FTPFileEntryParserImpl would be a no-op but the VMS case there would actually be a cache to empty. This solution preserves all the previous gains without preserving a lot of confusing APIs. It lets us safely deprecate FTPFileListParser. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] 1.2 release (Re: [net] checked in parser factory implementation)
In message <[EMAIL PROTECTED]>, steve cohen writes: >Except for the issue outlined below (re FTPFileListParser deprecation) my >latest commit have implemented everything that Daniel discussed earlier >today: Great! I added caching of the system name to avoid issuing SYST to the server for every listing. I also cached the entry parser to avoid creating a new one on every listing. Those changes assume the value of SYST never changes during the lifetime of an FTP session. If anyone knows that to be an invalid assumption, please say let us know so we can back out the optimization. >Once we have agreement on what to do about FTPFileListParser, I can make those I jumped the gun and deprecated FTPFileListParser and copied parseFileList to FTPFileEntryParser. It doesn't break anything and it's the direction we seemed to be headed in based on the current state of the discussion. We can always back it out if need be. I also deleted all of the code in DefaultFTPFileListParser and changed the class to extend UnixFTPEntryParser, adding a note indicating the class would be removed in version 2.0. That should take care of the maintenance issue Jeffrey raised while preserving a smooth migration. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] 1.2 release (Re: [net] checked in parser factory implementation)
I wrote: >Looking at the code, I would have to agree that parseFileList should >be preserved and move into FTPFileEntryParser. That allows us to >rewrite createFileList to call parseFileList instead of >FTPFileList.create, which allows the VMSFTPEntryParser to continue >doing its thing. Scratch that. I didn't realize how FTPFileList worked and where it was used. There may be a fundamental incompatibility here. In any case, I tested deprecating FTPFileListParser and adding the parseFileList method to FTPFileEntryParser. It doesn't cause any compilation or runtime problems. So that's a viable migration path. The problem that remains is in how to invoke parseFileList() when required (i.e., for VMSFTPEntryParser). The whole point of FTPFileList and FTPFileEntryParser was to perform incremental parsing, but parseFileList requires parsing of the entire input in advance. One way out of this is to add a boolean requiresEntireStream or similar method to FTPFileEntryParser, which FTPFileList can use to decide whether to call parseFileList, but that invites other kluges because FTPEntryParser implementations implement parseFileList by creating an FTPFileList in turn. I don't have a suggestion about this right now. Another question is whether we should encourage the use of FTPFileList over FTPFile[] for iterating over file listings. I thought that's where we were headed with Steve's code. Wouldn't that suggest we should deprecate FTPClient.createFileList and replace it with FTPFileList listFiles? We can get away with that because the createFileList methods have diferent signatures from the existing listFiles methods. But wouldn't we want to replace the existing FTPFile[] listFiles methods with ones that return FTPFileList? Alternatively, FTPFileList could be passed as a reference parameter to a void method (e.g., void listFiles(String pathname, FTPFileList list)), which would require a couple of modifications in FTPFileList, but would have the benefit of allowing the reuse of FTPFileList objects without creating garbage. Or is there no real gain to be had down that road? daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] 1.2 release (Re: [net] checked in parser factory implementation)
On Monday 05 January 2004 10:31 pm, Jeffrey D. Brekke wrote: > Couldn't we handle this with a FilterIterator or some other adapter on > the iterator from an FTPFileList? I never thought of this when the > version patch was submitted, but it seems like a possible solution. > Better than supporting multiple ways of parsing the list. This sounds like a good idea. There are all sorts of possibilities once we leave JDK 1.1 behind. I haven't thought too much about it but we could rewrite the VMS parser to use less of the base implementation. Also, the versioning scenario will not be supported under auto-detection. There are some issues here. > > Of course it wouldn't help for the methods that return an array, but > the user could sort that out also, converting the array to a list and > using the FilterIterator. > > > On Mon, 05 Jan 2004 14:27:22 -0600, steve cohen > > <[EMAIL PROTECTED]> said: > > > > There's still one problem with deprecating FTPFileListParser. The > > one method of this interface (parseFileList()) is used in the > > VMSFTPEntryParser. There is an implementation here that is distinct > > from the default one in FTPFileListParserImpl. > > > > This is for a very good reason. The idea of a File Entry parser (as > > opposed to a File List parser) was to parse each entry separately. > > This was a good idea and allowed for cleaner logic to be used. It > > made the business of not creating FTPFile objects until needed > > possible. > > > > The only problem here was in the VMS case where versioning is turned > > on. In that case the question of whether or not to "keep" an entry > > depends on the existence of other entries with the same name and > > different version numbers. In that case you do want a whole-list > > parsing mechanism. > > > > If we still want to deprecate FTPFileListParser, I would recommend, > > then, that we move parseFileList() into the FTPFileEntryParser > > interface. However, I wanted to throw this question out there for > > general comment before I do that. > > > > On Monday 05 January 2004 11:29 am, Daniel F. Savarese wrote: > >> I forgot to add that I think we need a beta release for 1.2 to give > >> us a chance to back out or fix anything that we discover is > >> suboptimal before we set the stuff in stone in the API. Mostly I'm > >> thinking of method signatures. Anyway, to recap the proposed > >> deprecation list: > >> > >> interfaces: FTPFileListParser classes: DefaultFTPFileListParser > >> methods: FTPClient.listFiles(FTPFileListParser, String) > >> FTPClient.listFiles(FTPFileListParser) > >> > >> Did I miss anything? > >> > >> daniel > >> > >> > >> > >> - > >> 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] 1.2 release (Re: [net] checked in parser factory implementation)
In message <[EMAIL PROTECTED]>, steve cohen writes: >There's still one problem with deprecating FTPFileListParser. >The one method of this interface (parseFileList()) is used in the >VMSFTPEntryParser. There is an implementation here that is distinct from the >default one in FTPFileListParserImpl. ... >If we still want to deprecate FTPFileListParser, I would recommend, then, that > >we move parseFileList() into the FTPFileEntryParser interface. However, I >wanted to throw this question out there for general comment before I do that. In one of my emails I started writing "I'm not entirely convinced we need to deprecate FTPFileListParser ..." but I couldn't really support that so I deleted that thought. You nailed the case where it makes a difference. The question remains though, how do we support this when the only way parseFileList is called is in listFiles(FTPFileListParser, ...), which we're deprecating and going to remove? I don't think we want the API user to have to be intimate with the different parsers and figure out when to call listFiles(FTPFileListParser, ...) and when not to. Moving parseFileList into FTPFileEntryParser won't solve the problem unless we make parseFileList the single entry point to creating file lists from FTPClient (since all of the FTPFileEntryParser implementations we have so far implement parseFileList). Looking at the code, I would have to agree that parseFileList should be preserved and move into FTPFileEntryParser. That allows us to rewrite createFileList to call parseFileList instead of FTPFileList.create, which allows the VMSFTPEntryParser to continue doing its thing. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] 1.2 release (Re: [net] checked in parser factory implementation)
In message <[EMAIL PROTECTED]>, "Daniel F. Savar ese" writes: >I forgot to add that I think we need a beta release for 1.2 to give us I also forgot to add that there's at least one pending code submission/patch that we need to review and include before a 1.2 release. I believe it was the NTP/SNTP functionality submitted by Jason Matthews. We may need a signed CLA before we can include it should it pass muster. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] 1.2 release (Re: [net] checked in parser factory implementation)
Couldn't we handle this with a FilterIterator or some other adapter on the iterator from an FTPFileList? I never thought of this when the version patch was submitted, but it seems like a possible solution. Better than supporting multiple ways of parsing the list. Of course it wouldn't help for the methods that return an array, but the user could sort that out also, converting the array to a list and using the FilterIterator. > On Mon, 05 Jan 2004 14:27:22 -0600, steve cohen <[EMAIL PROTECTED]> said: > There's still one problem with deprecating FTPFileListParser. The > one method of this interface (parseFileList()) is used in the > VMSFTPEntryParser. There is an implementation here that is distinct > from the default one in FTPFileListParserImpl. > This is for a very good reason. The idea of a File Entry parser (as > opposed to a File List parser) was to parse each entry separately. > This was a good idea and allowed for cleaner logic to be used. It > made the business of not creating FTPFile objects until needed > possible. > The only problem here was in the VMS case where versioning is turned > on. In that case the question of whether or not to "keep" an entry > depends on the existence of other entries with the same name and > different version numbers. In that case you do want a whole-list > parsing mechanism. > If we still want to deprecate FTPFileListParser, I would recommend, > then, that we move parseFileList() into the FTPFileEntryParser > interface. However, I wanted to throw this question out there for > general comment before I do that. > On Monday 05 January 2004 11:29 am, Daniel F. Savarese wrote: >> I forgot to add that I think we need a beta release for 1.2 to give >> us a chance to back out or fix anything that we discover is >> suboptimal before we set the stuff in stone in the API. Mostly I'm >> thinking of method signatures. Anyway, to recap the proposed >> deprecation list: >> >> interfaces: FTPFileListParser classes: DefaultFTPFileListParser >> methods: FTPClient.listFiles(FTPFileListParser, String) >> FTPClient.listFiles(FTPFileListParser) >> >> Did I miss anything? >> >> daniel >> >> >> >> - >> 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] -- = Jeffrey D. Brekke [EMAIL PROTECTED] Wisconsin, USA [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] 1.2 release (Re: [net] checked in parser factory implementation)
Except for the issue outlined below (re FTPFileListParser deprecation) my latest commit have implemented everything that Daniel discussed earlier today: Cleanup of File parsing interface: Deprecate class DefaultFTPFileListParser Remove __defaultFileListParser from FTPClient Deprecate FTPClient.listFiles() methods that take a FTPFileListParser param For those FTPClient.listFiles() methods that do not take a FTPFileListParser param, reimplement as per previous FTPClient.getFileList() methods Remove FTPClient.getFileList methods Change ParserInitializationException to inherit from RuntimeException Add FTPFileEntryParserFactory member to FTPClient and initialize this member to a new DefaultFTPFileEntryParserFactory. Add a set() method for this member. Remove logic that attempts to initialize this member based on a system property. Once we have agreement on what to do about FTPFileListParser, I can make those changes as well Steve On Monday 05 January 2004 02:27 pm, steve cohen wrote: > There's still one problem with deprecating FTPFileListParser. > The one method of this interface (parseFileList()) is used in the > VMSFTPEntryParser. There is an implementation here that is distinct from > the default one in FTPFileListParserImpl. > > This is for a very good reason. The idea of a File Entry parser (as > opposed to a File List parser) was to parse each entry separately. This > was a good idea and allowed for cleaner logic to be used. It made the > business of not creating FTPFile objects until needed possible. > > The only problem here was in the VMS case where versioning is turned on. > In that case the question of whether or not to "keep" an entry depends on > the existence of other entries with the same name and different version > numbers. In that case you do want a whole-list parsing mechanism. > > If we still want to deprecate FTPFileListParser, I would recommend, then, > that we move parseFileList() into the FTPFileEntryParser interface. > However, I wanted to throw this question out there for general comment > before I do that. > > On Monday 05 January 2004 11:29 am, Daniel F. Savarese wrote: > > I forgot to add that I think we need a beta release for 1.2 to give us > > a chance to back out or fix anything that we discover is suboptimal > > before we set the stuff in stone in the API. Mostly I'm thinking of > > method signatures. Anyway, to recap the proposed deprecation list: > > > > interfaces: > >FTPFileListParser > > classes: > >DefaultFTPFileListParser > > methods: > >FTPClient.listFiles(FTPFileListParser, String) > >FTPClient.listFiles(FTPFileListParser) > > > > Did I miss anything? > > > > daniel > > > > > > > > - > > 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] 1.2 release (Re: [net] checked in parser factory implementation)
There's still one problem with deprecating FTPFileListParser. The one method of this interface (parseFileList()) is used in the VMSFTPEntryParser. There is an implementation here that is distinct from the default one in FTPFileListParserImpl. This is for a very good reason. The idea of a File Entry parser (as opposed to a File List parser) was to parse each entry separately. This was a good idea and allowed for cleaner logic to be used. It made the business of not creating FTPFile objects until needed possible. The only problem here was in the VMS case where versioning is turned on. In that case the question of whether or not to "keep" an entry depends on the existence of other entries with the same name and different version numbers. In that case you do want a whole-list parsing mechanism. If we still want to deprecate FTPFileListParser, I would recommend, then, that we move parseFileList() into the FTPFileEntryParser interface. However, I wanted to throw this question out there for general comment before I do that. On Monday 05 January 2004 11:29 am, Daniel F. Savarese wrote: > I forgot to add that I think we need a beta release for 1.2 to give us > a chance to back out or fix anything that we discover is suboptimal > before we set the stuff in stone in the API. Mostly I'm thinking of > method signatures. Anyway, to recap the proposed deprecation list: > > interfaces: >FTPFileListParser > classes: >DefaultFTPFileListParser > methods: >FTPClient.listFiles(FTPFileListParser, String) >FTPClient.listFiles(FTPFileListParser) > > Did I miss anything? > > daniel > > > > - > 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]
[net] 1.2 release (Re: [net] checked in parser factory implementation)
I forgot to add that I think we need a beta release for 1.2 to give us a chance to back out or fix anything that we discover is suboptimal before we set the stuff in stone in the API. Mostly I'm thinking of method signatures. Anyway, to recap the proposed deprecation list: interfaces: FTPFileListParser classes: DefaultFTPFileListParser methods: FTPClient.listFiles(FTPFileListParser, String) FTPClient.listFiles(FTPFileListParser) Did I miss anything? daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
