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 <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]

-- 
=====================================================================
Jeffrey D. Brekke                                   [EMAIL PROTECTED]
Wisconsin,  USA                                     [EMAIL PROTECTED]
                                                    [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to