FTP - Can we get along?
Interesting reply.I apologize for being insensitive or touchy. My argument was about products not people, any identification between them was unintended, but I had to ask *somebody* knowledgeable, and I did so offline, so as not to pollute the list. Since an all-out flame is not what a public list wants, I'll do everythingI can to avoid this kind of reaction, while still making it known that significant problems and workarounds are in unresolved tension. I think my prior post was too strong, let's keep only the data portion of it. This is what I know: 1 - Of 217 tests performed with FTP functionality in MC, in succession, about 40 worked without incident. They were small text files.2 - The error rate appears to increase when multiple files are sent, or when there is more than 2 or 3 FTP calls per invocation of MC. 3 - Another member's post stating that Quitting MC fixes the problem is also corroborated by my experience. 4 - The following is beneficial for FTP robustness: if not (the stacksinUse contains "libURL") then start using "liburl" set socketTimeoutinterval to 10 send "resetAll" to stack "libURL"but we should understand that resetAll immediately closes open sockets, which may trunc pending writes or reads.5 - the HTTP functionality of libURL has worked 100% of the time. *** This is what I believe: 1 - If you have FTP needs, particularly for single transmissions, then the probability is that libURL will work very well.2 - If the FTP client goes offline (I deploy on a network of computers in NYC, NJ, Massacusetts, and California), for instance, when a DSL or gateway connection is lost, the user will not know, but libURL should.3 - Metacard *is* a fantastic tool. I have no idea what the support structure is, or what we can expect when lingering questions arise.4 - Metacard has an address ([EMAIL PROTECTED]) which is accessible for support questions. It seems that Scott Raney is the person who answers from there, and perhaps that's a better venue for technical questions. I retract the request for an FAQ for MC FTP usage. I'll take responsibility for that, and it will be as accurate only as I can make it. Whoever is interested in the URL for it, let me know. Andu's angry reply correctly points out inaccuracies in my statements - I'm not an expert with libURL. It is why I asked for help. I don't know who is responsible for libURL, or if it is a volunteered stack. If the latter is the case, I doubly apologize -- it was not common knowledge. I thought it was part of v2.4. But iflibURL was goodwill work,its authors certainly deserve more forbearance than I've given them, despite any reliability issues. I don't even know who authored it. I don't mean this as an insult to anyone: Why don't we create a thread for FTP users, so we can identify and focus on dialoguerelevant to specific details with consistency problems? For myself, I won't flame or ignore anyone's email. Cheers to all, and apologies to Andu. andu [EMAIL PROTECTED] wrote: Contradiction please. Dennie is *correct* in pointing out prevalent and irritating performance irregularities with libURL. I too have had great hopes for MC FTP, but after hundreds of tests, can confirm only too well exactly the same results. More disheartening is that one week ago, I sent the same information to a prominent member of this list, going so far as to ask for an MC FTP FAQ. The plea has been ignored.So you are pissed I didn't get to answer your email. I would've done itinstantly have I known you were so touchy.Let me get something straight to you in case you didn't notice, I spentmany hours on this list helping people out with different mattersrelated to sockets, protocols, syntax and so on and I did it out ofpleasure not obligation. A good part of your unanswered mail deals withsyntax related to reading fi! les not ftp, although I will provideinstructions for whatever the library does, I will not make it my job tojump on every bad syntax issue and bring light to the masses with a FAQ.There is documentation for reading/writing files, if people invent theirown syntax, let them.The library has been in testing as long as MC 2.4 has, most of theissues brought to my attention were related to HTTP and I tried dealingwith them as fast as I could.People discovered ftp in the past 3 weeks or so and again, I fix bugs assoon as they are found, by me or others. Some bugs I can't fix because Ican't reproduce them.You went "so far as to ask for an MC FTP FAQ". What is that supposed tomean? From prior experience with PERL socket programming, I've tried scripting defensive safeguards and checks in libURL, but it just as often fails surreptitiously. Many questions have arisen in this list over MC's FTP irregularities. As s! omeone who has spent too much time fighting it, my challenge is that this code should be stabilized, and clarified via FAQ, or brought back into the shop as not being ready for production use. You stabilize and clarify your code via FAQ, I'll let
Re: FTP - Can we get along?
On Fri, 5 Oct 2001 F. Ricardo, Ph.D. [EMAIL PROTECTED] wrote: Interesting reply.I apologize for being insensitive or touchy. My argument was about products not people, any identification between them was unintended, but I had to ask *somebody* knowledgeable, and I did so offline, so as not to pollute the list. Since an all-out flame is not what a public list wants, I'll do everything I can to avoid this kind of reaction, while still making it known that significant problems and workarounds are in unresolved tension. I think my prior post was too strong, let's keep only the data portion of it. This is what I know: 1 - Of 217 tests performed with FTP functionality in MC, in succession, about 40 worked without incident. They were small text files. 2 - The error rate appears to increase when multiple files are sent, or when there is more than 2 or 3 FTP calls per invocation of MC. 3 - Another member's post stating that Quitting MC fixes the problem is also corroborated by my experience. 4 - The following is beneficial for FTP robustness: if not (the stacksinUse contains libURL) then start using liburl set socketTimeoutinterval to 10 send resetAll to stack libURL but we should understand that resetAll immediately closes open sockets, which may trunc pending writes or reads. 5 - the HTTP functionality of libURL has worked 100% of the time. 6 - You never sent a bug report about this problem to [EMAIL PROTECTED] or [EMAIL PROTECTED], but instead sent it to this list which is *not* where these kinds of things should be sent because we normally only pick out the most interesting anomolies from this list for further examination. FTP problems (and indeed most libURL problems) don't fall into this category because problems FTPing even using browsers and dedicated FTP programs are so common as to mask any problems with the programs themselves. *** This is what I believe: 1 - If you have FTP needs, particularly for single transmissions, then the probability is that libURL will work very well. I think this is highly dependent on the server you use. In our tests ftp: URLs works reliably, but this is admittedly a relatively easy test for libURL because they're all local UNIX systems we've tested with before, ruling out network congestion and possibly more persistent incompatibility problems that may occur with some servers. 2 - If the FTP client goes offline (I deploy on a network of computers in NYC, NJ, Massacusetts, and California), for instance, when a DSL or gateway connection is lost, the user will not know, but libURL should. Possibly, though in most cases getting a socketTimeout message would be the only way. Certainly it's not as simple as using try..catch or any other sort of error handling because even in the rare cases where the error can happen immediately when a command is executed, it'll be returned in the result rather than causing an execution error. 3 - Metacard *is* a fantastic tool. I have no idea what the support structure is, or what we can expect when lingering questions arise. You can expect bugs to be fixed, but only if you send detailed reports about them to us. I can't FTP is not specific: we need to know what server, more about what type of system and what kind of connection you have to the server, and whether you're sure you can reliably get to that from another program (browser or dedicated FTP program). 4 - Metacard has an address ([EMAIL PROTECTED]) which is accessible for support questions. It seems that Scott Raney is the person who answers from there, and perhaps that's a better venue for technical questions. Exactly. I retract the request for an FAQ for MC FTP usage. I'll take responsibility for that, and it will be as accurate only as I can make it. Whoever is interested in the URL for it, let me know. Sounds good. I actually expected a bit more participation of this type since we decided to move URL processing out into a separate open source library. While a few people have been diligent in sending in reports, there's been (apparently) relatively little examination of the libURL script itself and almost no contributions to improving it. Andu's angry reply correctly points out inaccuracies in my statements - I'm not an expert with libURL. It is why I asked for help. No problem, so as long as what you're really doing is asking for help and not reporting a bug or just whining, messages containing such things should go someplace else ;-) I don't know who is responsible for libURL, or if it is a volunteered stack. If the latter is the case, I doubly apologize -- it was not common knowledge. I thought it was part of v2.4. But if libURL was goodwill work, its authors certainly deserve more forbearance than I've given them, despite any reliability issues. I don't even know who authored it. It is a supported part of the product, though admittedly a very new part and one that still needs
Re: FTP - Can we get along?
Scott Raney wrote: 3 - Metacard *is* a fantastic tool. I have no idea what the support structure is, or what we can expect when lingering questions arise. You can expect bugs to be fixed, but only if you send detailed reports about them to us. I can't FTP is not specific: we need to know what server, more about what type of system and what kind of connection you have to the server, and whether you're sure you can reliably get to that from another program (browser or dedicated FTP program). I have a tip for submitting bugs that I've found is very helpful when I get them from my own customers, and I've seen Scott respond almost instantly with confirmation when I take the time to do this: If possible, see if you can create an isolated example stack that illustrates the problem you're experiencing. Sometimes it isn't possible, but most of the time I've found that it's useful for myself as well. It lets me rule out other potential sources of trouble, and as often as not the time I take to isolate problems in this way shows me that the true source of the problem was not what I originally anticipated; in some cases I find that it's something I can fix myself and get back to work, but I wouldn't have known if I hadn't taken the time to slow down and really analyze the problem. Once you've isolated a problem and verified that it's something in the engine (or in this case, libURL), sending that to Scott with a step-by-step recipe for reproducing the problem will allow him to zero in on it quickly. And of course, the faster he can identify a problem the faster he can deliver a fix to us. I've found Scott Raney provides pretty much the best support in the industry, but I'll have to admit that my appreciation for his efforts has grown with my own self-discipline in problem analysis. When I used to submit really sloppy reports, I didn't get the results I wanted; when I provide a good recipe or example stack, most of the time I see a fix in the very next build. -- Richard Gaskin Fourth World Media Corporation Multimedia Design and Development for Mac, Windows, UNIX, and the Web _ [EMAIL PROTECTED] http://www.FourthWorld.com Tel: 323-225-3717AIM: FourthWorldIncFax: 323-225-0716 Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to [EMAIL PROTECTED], not this list.
