commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jbre...@wi.rr.com (Jeffrey D. Brekke)
Subject Re: [net] 1.2 release (Re: [net] checked in parser factory implementation)
Date Wed, 07 Jan 2004 13:38:18 GMT
>>>>> On Wed, 07 Jan 2004 05:44:36 -0600, steve cohen <scohen@javactivity.org>
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 >>>>>
>> <scohen@javactivity.org> said:
>> >
>> > On Tuesday 06 January 2004 07:08 pm, Daniel F. Savarese wrote:
>> >> In message <200401061628.50504.scohen@javactivity.org>, 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:
>> commons-dev-unsubscribe@jakarta.apache.org > For additional
>> commands, e-mail: commons-dev-help@jakarta.apache.org


> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org

-- 
=====================================================================
Jeffrey D. Brekke                                   jbrekke@wi.rr.com
Wisconsin,  USA                                     brekke@apache.org
                                                    ekkerbj@yahoo.com


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message