[dcc2] Question about the necessity of multi file sends

[codemastr]

[comprehensive reply]

> One thing a client could do with multi sends that it could not do with a
> .zip file (and a single, simple dcc request) is decline individual files
> based on file type or some other criteria.  Perhaps I want to accept files
2
> and 4 but want to skip 1 and 3?  A multi send protocol can be defined to
> allow that; zipping everything up and sending it along does not, and the
dcc
> request received by the client doesn't even indicate what kind of files
are
> inside.

Ok, I can see that being useful. However, I don't see anything that really
says you are allowed to skip (or even request files out of order). Again,
looking at the example (these drafts seem to rely heavily on examples, bad
idea imho), it does files 0, 1, 2. It doesn't mention you could do 0, 2 if
you wanted to. I'd assume you can, but it doesn't actually say it. If that
is allowed, I can see that as being a strong point I suppose. However, I
will point out that multi sends don't solve this problem. I don't see
anything that says "clients will ignore files ending with .zip, .tar, .gz,
etc." So if people still want to use zip files, they will. So adding multi
sends doesn't really make us anymore secure than we already are. The good
users would continue to be good, and the bad users would continue to be bad.

That I suppose is the only valid argument for it though. The stuff people
said about not knowing how to use zip I already proved was unnecessary. The
user selects a group of files to send, the IRC client zips them up, and the
receiver auto extracts. Not exactly a secure method, but it would prevent
the user from ever having to worry about what a zip file is. If the draft
was indeed meant to imply you can deny some files and accept others, then
yes I can see that as being useful.

> The final reason I support it is that we never know what the future could
> bring, maybe if we impliment it, someone down the road will come up with a
> really neat way to use it.

It's just as likely that someone will come up with a really malicious way to
use it. So I don't think you can use that as a valid argument.

>Multi-file sends are already present in most major IM chat clients, and we,
as IRC client
> authors, have already decided that this is a feature many of us want to
add  for our users as well.

Once again I point out that none of the major clients have jumped in
proclaiming their support for multi file sends. So while all the client
coders here might support it, if we summed up all the IRC users that dirc,
virc, kvirc, ircle, klient, bersirc, ornateirc, chatzilla, and babbel have
combined, I doubt it would be more than 10% of IRC users, and that's
probably pushing it. So the coders here may want it, but in the overall
scheme of things, you're still only a small portion of the IRC community. If
Khaled sent a message to this list saying he intends to add multi file sends
to mIRC, then I'd say go ahead, but right now, the impression I get is that
the mIRC community is against this feature. I also don't think saying "IM
has it, so should IRC" is valid. I personally like the idea of smileys. I
think having graphical smileys in a client is a great idea. However, any
time I suggest this (as Tom can attest to) I,and others, get replies of
"this is IRC, not AIM. If you want smileys, use an IM client." Even just
last night on IRC-Junkie I saw someone using that argument to say 30
character nicknames have no place on IRC saying if you want 30 chars, use
IM, not IRC. My point is again, this is an argument that can go both ways.
You argue, it works in IM, so try it in IRC. Others will argue that they
don't want IRC to become IM.

> Why not argue the technical merit of the implementation, rather than the
> political ramifications of it. Otherwise I fear this group will end up
split
> based on personal beliefs rather than united on techical superiority.

Saying argue technical merit, not politics, I'd say "welcome to IRC." If you
don't know by now that IRC is *very* political in nature, then perhaps
should take a good look around. In a perfect world, yes, everything would be
based on merits. But IRC is not a perfect world. How many hundreds of IRC
networks have fallen apart because of politics? Politics is a very real part
of IRC, and we'd be foolish to ignore it when developing a standard for IRC.
I'm looking at this as a pragmatist. Again, you'll notice that none of the
major clients have joined this group as of yet. If they don't come on board,
I think we can all agree, DCC2 will be doomed to failure. I don't know how
many times I've seen the moderators on the mIRC forums (who, to my
understanding are hand picked by Khaled) say that mIRC is for chatting, not
for filesharing. In my mind that expresses the idea that the mIRC people are
likely to be against such things. I could be completely wrong of course, but
that's the feeling I get. My point is, if you turn DCC2 into something that,
politically, the IRC community is against, then you will never gain the
support necessary to make it successful. It's sad, but it's reality.

Personally, I do want to see DCC2 go forward. Not for multisends, but for
other things. I've always supported the idea of DCC video and voice chat. It
would be great if they were standardized rather than everyone doing their
own thing. But as I said before, if the IRC community doesn't like the
draft, you can be sure that the draft will fail. It's unfortunate that a
single feature could cause people to hate the whole thing, but that's the
way IRC is.

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.

-- codemastr