> File leachers? You are worried about those?
That's what I've said many times over now.
> What ebout people who use IRC to hold meetings and
> transfer project files (yes, I do know people who do that)....
> there are legitimate uses.
The people who hold meetings over IRC to transfer project files can still do so using existing DCC technology and I doubt they'd really care too much about the small speed increase because it's not like they're transferring project files 24/7. Also, as a programmer myself, I've hardly ever used IRC to transfer files, I use FTP servers, CVS, email etc...
> Besides 'leachers' as you call
> them don't use IRC they use other means, such as Kazaa.
Leeching first started on IRC and FTP servers, and yes now people are using Kazaa and such but there is still alot of leechers on IRC. I don't want to see this increase.
> Script it?
> Ok, so either one programmer codes it in or every one who
> wants support needs to script it.
What's your point? Lots of programmers already script heaps of similar stuff, e.g. away scripts, mp3 players, etc... what's wrong with heaps of people scripting this file sending support? It's an open protocol isn't it? People shouldn't have interoperability issues.
> Also, what about people who odn't know how to script?
This is a stupid point. They'll just go download a script. Ever heard of mircscripts.org?
> And yes, RFC date does matter. Because numerous other
> RFCs have been released announcing additions to the IRC
> and CTCP formats.
That does not mean that you have to adopt those additions. Noticed how DALnet and Undernet don't support the ircx?
FYI, there is no
RFC for CTCP.
> So mIRC is going to ignore the new
> RFCs and consentrate on the old one?
AFAIK Khaled isn't consentrating on the OLD or the NEW specs for sending files. He's implemented file sending functionality and he's moved on.
> Nothing has changed in the new ones, just the new ones
> append to the origional. What you are proposing (although
> on a smaller scale) is the equivilent of obeying the
> constitution but ignoring the ammendments.
No, I am not. A constitution is law. RFCs are not - you can choose to support them, or not. There is no requirement that you must adopt 'ammendment' RFCs.
> * Will only take an hour to program
You have to debug it. Test it for a multitude of different things. An hour is a gross underestimate or a sloppy job.
> * Will allow support for newer clients
You can script the functionality. Your point is invalid.
> * Will comply with the newest RFCs
Compliance is not a requirement. I don't see everyone around the world rushing to implement IPv6 or ircx.
> * Will save scriptors time and give the feature to
> people who don't know how to script.
Scripters will probably want to script it anyway. If not for fun but for added features. Your point about those who don't know how to script is invalid. Once again, they can just download a script.
> Why not to?
> * Will take time away from other project - not true unless
> you consider an hour a lot of time
As I've stated above, your hour of time is a gross underestimate of what is involved in producing quality code.
> * Will allow leachers/pirates to do faster transfer - true but
> it will also allow legitimate users to do it to
And as I've stated previously, legitimate users will not really notice the difference as most file sending is a once in a while, casual basis where speed is irrelevant. DCC already provides decent performance.
> * IRC is a chat client - true, it is a chat client. But now with
> instant messangers file transfer is a big part of being a chat
> client. Why keep IRC stuck in the past?
What's your point? (m)IRC has file transfer features. So does Instant Messangers. (m)IRC isn't stuck in the past. You should've been pointing out the performance of IM clients as compared to mIRC... I would've pointed out that I'm quite happy to see people send files over IM instead of mIRC. We won't be missing anything.
