[dcc2] Question about the necessity of multi file sends

[Dave Johnson]

codemastr writes:
> I think, at the very least, the draft should make it perfectly clear that
> multi file sends are an optional feature. That will at least convince some
> of the coders who are completely against the idea from abandoning DCC2
> completely.

I'm in agreement with that.  I wasn't thrilled with multi-file
transfers when it was XML, now that the format is simpler I may add
it, but it definately should not be a requirement.

One of the benifits to the multi-file mechanism was to add additional
metadata that may not fit in a CTCP message, and I still think that's
it's best feature.

It'd be nice to allow all the metadata you can currently do in a
multi-file connection through the CTCP negotiation. If we allow that,
then the usefulness of the multi-file interface starts to disapear,
especially considering the added complexity to an implementation.

I don't think multi-file functionality is going to make people want to
implement or use DCC2, it's just not useful enough.

What will make it a success and our focus should be on is:

* robust automatic NAT/firewall detection and traversal
    (this alone will make DCC2 a success or failure)
* encrypted/authenticated transports
* good error handling and reporting(&&)
* backwards compatibility with DCC1(**)
* file meta-data



&& The error tokens and error message are a good start, but we need
   timeouts, abort, cancel/disconnects to be defined too.


** I dont like how the negotiation draft currently relies on an
   assumption for backwards compatibility.  We need to come up with a
   better approact to backwards compatibility.  One way would for a
   client to send both a DCC2 followed by a DCC1 message where the
   DCC2 message references the DCC1 message (such as refering to the
   listen port number).  If the receiving client supports DCC2 it
   ignores the DCC1 message (because it already got a DCC2 message),
   if the receiving client does not is ignores the DCC2 message.

-- 
Dave