>>>>> 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
>> >> 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]
--
=====================================================================
Jeffrey D. Brekke [EMAIL PROTECTED]
Wisconsin, USA [EMAIL PROTECTED]
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
