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 100000
> 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 testing and tuning, Internet protocols
being an area with a lot of variability in implementation and an area
where reliability is much harder to achieve than in other areas of the
engine. Andu has been the primary person developing it (under
contract from MetaCard Corporation), but bug
reports/suggestions/complaints/etc. should go to [EMAIL PROTECTED]
and not to him. We don't want to stand in the way of expedient
followup communication, but I would appreciate being on the CC list on
any libURL related commucation.
> 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 dialogue
> relevant to specific details with consistency problems? For myself,
> I won't flame or ignore anyone's email.
Better yet, if you've got a problem, do what you can to isolate it to
a particular server or time of day or sequence of operations or
whatever and file a bug report. And if you've got the time and the
inclination, learn a little about the protocol and the libURL scripts
and use the debugger and maybe a TCP monitor (like Interarchy) to try
and isolate the problem. As it stands, I believe Andu has done an
excellent job at getting the basic protocol working reliably, but
there are still boundary and error conditions that it doesn't catch or
doesn't report back to the scripts that refer to URLs. Which is why
we need those bug reports and suggestions...
Regards,
Scott
********************************************************
Scott Raney [EMAIL PROTECTED] http://www.metacard.com
MetaCard: You know, there's an easier way to do that...
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.
