Sorry if this is a double post - I got a message saying it bounced... > >> In truth, I used LWP because I was already using it in > >> another part of the program, and because I thought the > >> 'head' and 'getstore' functions would do > >> what I needed (so it was out of laziness more than anything). > > > > These are very good reasons. The situation should be allowed > > to dictate which tools are used, and I (we) know very little > > about your situation. Should you use a hammer to pound in a nail? > > Not if you are on the roof of a 3 story house, the nail is > > really big, the only hammer you have access to is for finishing > > nails and is in the basement *and* there is a > > brick laying beside you.... > > ...unless the nail you need to pound in is also in the basement. :) > > >> Now that I look at it, I agree Net::FTP looks like a more > >> appropriate module than LWP. It appears to be purely OO, though, > >> and I prefer a more procedural interface - do you know if > >> Net::FTP supports that? > > > > Not sure... doubt it though, because of how Perl handles > OOP you could > > just hack it up in a procedural way, though I wouldn't necessarily > > suggest it. > > That's what I thought. I guess I'll have to stick with the > OO methods for that. (I don't have anything against OOP - > it's just harder for me to get my head around it. In my > case, it's not a coincidence that 'oops' is simply the plural > of OOP. Oddly enough, though, I make extensive use of > references to complex data structures, which seem perfectly > logical to me...) > > >> That said, would Net::FTP still be the preferred module if > >> the file you're downloading is NOT on an ftp server? For > >> example, I am downloading flat text data files. Some of > >> them are on an ftp site (cue Net::FTP, stage right), but > >> some of them aren't. Specifically, they have a http > >> address and, when the link to them is clicked, they are > >> displayed as text instead of downloaded. So would LWP be > >> appropriate for those files, or would Net::FTP still be the > >> way to go? > > > > Net::FTP would not be the way to go, likely *can't* be the > > way to go at least for the HTTP files. This is where an > > underlying understanding of what FTP and HTTP really are, comes > > into play and how they function in the client/server model. > > If the remote host provides a file via HTTP it may not (likely > > won't) provide the same file via FTP, and vice versa. > > This makes LWP a good tool since it provides the same > > interface to both protocols, essentially by reducing the > > protocols to their common factors. Otherwise you would need > > to code in a check that establishes whether a link is FTP or > > HTTP and call different code for each different type, which is > > why the LWP interface is so nice (and essentially what it > > is doing) for parsing links that are contained in webpages and > > just getting whatever is at the other end. > > Very good discussion - thanks. I will know ahead of time > which files are using which protocols, so I don't need to > code the logic to check the link, I'll just call the > appropriate function/method (in LWP or Net::FTP). > > > Is it more important to you to have a unified interface, > only need to > > support a single module, etc. Or is it better to have maximum > > flexibility and power at the cost of having to maintain multiple > > interfaces and modules? Only your situation (including what you > > consider production code, how long it takes to > > release/migrate, testing requirements, physical resources, etc.), > > needs, and future expectations can really tell you... > > I try to learn as much as I can from those that are smarter > than I, and use the right tool for the job (reference to > hammer/nail analogy above). Since this particular program is > more of a production tool than a "one-off" script, I'd much > rather rewrite a section so it's less of a kludge and easier > to maintain than take the easy way out now and regret it > later (maintenance, etc). > > > But to decide it helps to know all of the possiblities. > > Which is where you, the rest of this list, and Tim (Toady) > come in. Thanks to all for educating us beginners about > alternative ways of doing things. > > Bob >
-- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] <http://learn.perl.org/> <http://learn.perl.org/first-response>
