> Well, both would probably support PASV at ftp-level, true. But... What
if -
> for example - one of those hosts are behind a firewall that makes it
harder
> to use PASV on? Then you'd want to use PASV on the _other_ host and
use
> PORT on the firewalled host...

Let me check if this approach (of switching primary and secondary
connections) works.

> How do we know what data in the duplicated struct that we must clean
up
> after this failure? We must only free() data that was allocated after
> the cloning...

The cloned connection data is the same as other connection data.
Why it should be different? It should be cleaned as any other data.

> I'm not arguing about the 'source' part but about the 'ftp' part in
> protocol-agnostic code. If another protocol would add this support,
> you'd have source and target, yes, but the host wouldn't be FTP.

Oh, in this case we can use source_host, source_port, source_user, etc.
without 'ftp' part.
But on the other hand, for FTP you already have ftpport. Let's do it
consistently.
Also the option should be SOURCE_HOST, ... without the 'FTP' part.
Just let me know how you prefer to use the names and I will change them.

> It isn't the _only_ way, but it is one way. And since the second
connection
> is related to that connection it could make sense to have this pointer
like
> this.

This is exactly what I mean.

> ... but I want them documented in the curl_easy_setopt.3 man page!

I know, but there is no reason to copy and send you the same text from
the original documentation adding that this option will be used only in
3rd party transfer. I am sure you can do it by yourself. :-)

> ... there is only we who are here and we all already struggle
> hard to find time to do whatever we do.

After we finally close all the open issues and the code will be
implemented in some pre-release version, I will try to write the tests
with your help (I hope).
But if you need only the test cases - I can already supply them.

> > The sec_conn connection is closed as any other connection
> > when disconnecting.
> Ok, I simply must've missed that when I read through the code.

... and I already did some improvements in the patch.

> It is very easy, just run configure with --enable-debug, set the
> necessary environment variable and you're set to verify that your
> additions don't leak memory.

Thanks, I will do it.

> I don't follow you here, can you elaborate?
> What about if we (in the 3rd party case) just provide CURLINFO_TEXT
> chunks with "host %s sends this:" or "host %s receives this:" before
> the actual data/header callbacks are called?

I mean the same:
Preparing string variable "info" that includes host + ": " + ptr
before the data/header callbacks are called and send it instead of ptr.

In the Curl_debug() we don't know if the data was sent or received (or
may be I wrong?). I took the syntax of "host: " from the standard FTP
CLI used by SUN and HP.

The information contained in this message is proprietary of Amdocs,
protected from disclosure, and may be privileged.
The information is intended to be conveyed only to the designated recipient(s)
of the message. If the reader of this message is not the intended recipient,
you are hereby notified that any dissemination, use, distribution or copying of
this communication is strictly prohibited and may be unlawful.
If you have received this communication in error, please notify us immediately
by replying to the message and deleting it from your computer.
Thank you.
Received on 2004-05-28