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.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 <ftp> 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
