Forums Feature Suggestions DCC SEND is horribly out of date

The DCC SEND command has two things that make it out of date:
1) Is that it still uses IPv4 encoding for the IP address. There is very little documentation on it, it is out of date, and causes problems with other IRC clients. It should at the very least
2) The command itself is out-of-date. Instead, XMIT should be used. To maintain backwards compatibility, SEND can still be enabled but right now XMIT doesn't even seem to be supported.

Does DCC SEND work? Yes.
Does mIRC need DCC XMIT right now? No.

Improvement is always good, but there's really no NEED for this IMO =\

Regards,

SEND works yes. But what if some one using a newer IRC program that uses XMIT wants to send an mIRC user a file? They can't, unless they download an older IRC client or use another method. I just think mIRC should support both. It wouldn't be that hard, the only real difference between XMIT and SEND is that XMIT is faster because it doesn't require packet acknowledgement (which is redundent in SEND because TCP/IP takes care of that at a lower level).

Why not add support for XMIT? It should only take a little while to impliment and it would create compatability with a wider range of clients.

As far as my first comment, I meant to say 32-bit unsigned int network byte order IPv4 addresses (as opposed to 32-bit dotted notation IPv4 addresses). I just wanted to clarify that.

Two points:

- If the majority of people (or a large proportion of those that send files via IRC) use mIRC, then finding an XMIT only person isn't going to be too Easy.
- I don't think Khaled really wants mIRC to be known for being the best file swapping client

There is documentation on DCC, under the CTCP specification:
http://www.irchelp.org/irchelp/rfc/ctcpspec.html

Specifically, DCC <type> <argument> <address> <port> <size>

In case of DCC SEND, it would be:
DCC SEND <filename> <address> <port> <size>.

The command isn't out of date. By your argument, IRC would be obsolete because RFC 1459 was written in 1993.

If your client doesn't support DCC SEND, then that's your problem. DCC SEND is a "de facto" standard, and if the client chose not to support that, then that's something that you should take up with their coder.

i think xmit support is a great idea, and i dont quite get the point of you other people. just because the majority of users are using mIRC, it shouldnt be supported? thats quite stupid imo. you could still use send if you want to, xmit wouldnt break backwards compatibility at all. sometimes its just time to move on! also, if khaled doesnt want mirc to be a file-sharing tool, why did he include dcc at all? or even the fserv? if everyone would think like you, we'd all be chatting with telnet

telnet chatting rulz ;b
like a biiiig exersise that you have already solved with your grandma and now you want to beat alone ;b

Yeah, DCC SEND is really outdated and stupid. I can't see why people are trying to hold on to something like that. Do you want file transfers to be slower than they have to be? NO! The world goes forward and so does IRC.
I really do think that mIRC should support XMIT!!

mIRC already has one perfectly acceptable method of transferring files, which is used by every IRC client that I've used. Why waste more effort when the functionality to send files already exists?

> if khaled doesnt want mirc to be a file-sharing tool, why did > he include dcc at all? or even the fserv?

There are valid reasons to send files over IRC. However of the past 10 odd years people have found other, more illegal uses for it.

This is a case of marginal analysis. Should we ADD EXTRA features to an existing set? Is the marginal benefit worth it? (Ever did Economics??). There is a benefit in Khaled keeping the existing DCC features and there is a benefit in not improving those features. He's found the right level of functionality for DCC.

Remove DCC and people will go to other clients or older mIRC versions. Improve DCC and he'll most likely be getting mIRC a rep. worse than Kazaa.

> Do you want file transfers to be slower than they have to
> be? NO! The world goes forward and so does IRC.
> I really do think that mIRC should support XMIT!!

Perhaps it's an advantage. People who download warez and pr0n using IRC channels are encouraged to go elsewhere as it's too slow on IRC. Meanwhile those who just want to send a file to a mate e.g. a personal picture, funny wav, etc... will still be happy as the speed of a one-off transfer really is quite irrelevant and unimportant.

Sounds like a win-win to me.

>mIRC already has one perfectly acceptable method of transferring files, which is used by every IRC client that I've used. Why waste more effort when the functionality to send files already exists?

Duh, DCC SEND is not perfect! I think it's the most stupid protocol there is.

> Improve DCC and he'll most likely be getting mIRC a rep. worse than Kazaa.

Yeah, sure. Kazaa is only made for file swapping - mIRC is not. So, i can't see how it could get a wrose rep. than Kazaa. It isn't even the same type of software.
And the best thing with IRC is that you can easily stay away from things you don't want to take part of. You could easily stay away from this too. Or are you afraid that the feds are going to take mIRC away from you? It's never going to happen. They can't make every app, that can send files, illegal. Should file transfers in your browser/ftp client also be slower than they have to be, to stop people from sharing warez and stuff? Where is the logic?

> Duh, DCC SEND is not perfect! I think it's the most stupid
> protocol there is.

I said it was a perfectly acceptable method. Not a perfect method.

> Yeah, sure. Kazaa is only made for file swapping - mIRC is
> not. So, i can't see how it could get a wrose rep. than
> Kazaa. It isn't even the same type of software.

Exactly. mIRC currently is not a real file swapping client. Doing things like adding XMIT, limiting bandwidth functions, etc... to mIRC makes it more and more like a file swapping client. And so then mIRC's rep for being used for file swapping will grow, and get worse.

The fact that it is not the same type of software is irrelevant. It is what people are trying to make mIRC become which is relevant. It should also be noted that both programs share similar functionality in certain areas.


> And the best thing with IRC is that you can easily stay
> away from things you don't want to take part of.

And by your own logic, the best thing with mIRC not having a monopoly on IRC clients is your ability to go use a client of your own choice. You can easily stay away from mIRC if you don't like the way it's heading.

> Should file transfers in your browser/ftp client also be
> slower than they have to be, to stop people from sharing
> warez and stuff? Where is the logic?

An FTP client is designed for the transfer of files. A web browser is designed for the transer of files. The primary purpose of those two types of clients is the transfer of files. The primary purpose of an IRC client is not.

>And by your own logic, the best thing with mIRC not having
>a monopoly on IRC clients is your ability to go use a client of
>your own choice. You can easily stay away from mIRC if
>you don't like the way it's heading.

The way it's heading? It seems like you want it to stand still.
And the reason for it beeing used in an illegal way isn't reason enough for not adding it. Why don't you tell Khaled to remove DCC SEND all togheter? Listening to you, it would be the only way to go. So it doesn't get bad reputation among people that doesn't now anything anyway.

This has been said thousand of times - The chance of people using a feature in a "bad" way isn't a reason enough for not adding it. Why should the "bad" users disallow us other to using something that could help us? It won't hurt you or mIRC!

At last, mIRC have alot of useless features, that are not needed for irc, a better DCC SEND isn't one of them.

>The way it's heading? It seems like you want it to stand still.

In certain areas, yes. This is one of them.

>And the reason for it beeing used in an illegal way isn't
>reason enough for not adding it. Why don't you tell Khaled to
>remove DCC SEND all togheter? Listening to you, it would be
>the only way to go. So it doesn't get bad reputation among
>people that doesn't now anything anyway.

As I explained, this is a marginal thing. We've already got DCC SEND. Removing it won't help things - people will just use an older mIRC. Adding a new sending functionality will encourage more illegal downloads that it will in other areas. The only reason that people seem to be using for XMIT is that it's more efficient. What are the benefits of this efficiency, compared to the costs? Cost: lots of illegal downloads, benefit: slightly faster transfer speed. You do the math.

>This has been said thousand of times - The chance of
> people using a feature in a "bad" way isn't a reason
> enough for not adding it. Why should the "bad" users
> disallow us other to using something that could help us?

Because the feature has more bad than good. Fast file sending over IRC isn't really important, as I've said. There are programs specifically designed for file transfer. Next thing you know you'll be asking for gzip compression before sending.

> It won't hurt you or mIRC!

It will hurt mIRC's reputation.

> At last, mIRC have alot of useless features, that are not
> needed for irc, a better DCC SEND isn't one of them.

I've come across this argument MANY times and it's completely invalid. Just because useless features were put in the past does NOT mean that useless features should continue to be put in to mIRC. Ever heard of the expression 'to learn from your mistakes?'.

Here's a thought:

Why don't you just script it?

well I'm +1 for this feature

Just include it for the sack of support, and default to using SENDs all the time, unless another client requests the new protocal...

How can a new protocal ever get common place if one of the major IRC Clients doesn't even support it...

bramp

For some people I want to make clear that I did not intend to state that DCC SEND should be eliminated, just that DCC XMIT should be added (even if it only allows recieving and not sending the command).
As far as the RFC goes. Yes, XMIT is not specified in the origional RFC. But that is very old now. Might I also add that file resumming is also not in there. File resuming isn't even standard, it is a de facto standard set by mIRC and a few others. Resume isn't in the origional documents, should we get rid of that?

I have yet to see significant a reason not to support it. Other than the fact that some people are afraid of change. Of course you should keep DCC SEND but there is no reason not to add support for DCC XMIT.
Why not?

I'll tell you why... faster and more streamline transmitions and complience with cutting edge clients. Stop adding new features to the protocal and I guarentee you that in a few years mIRC will no longer be the leading IRC client. Even if I am wrong, why risk it?

> For some people I want to make clear that I did not intend to
> state that DCC SEND should be eliminated, just that DCC
> XMIT should be added (even if it only allows recieving and
> not sending the command).

Why not just write a script for it if you want it soo badly?

> Yes, XMIT is not specified in the origional RFC. But that
> is very old now

Another poster pointed out that the age of an RFC is irrelevant. Your point is invalid.

> I have yet to see significant a reason not to support it.

Waste of time implementing something for which we already have a satisfactory implementation for. Why reinvent the wheel?

> I'll tell you why... faster and more streamline transmitions
> and complience with cutting edge clients.

Is that speed increase that big? How many minutes a day will it save the average IRC user? Compare that to how many minutes a day it would save the average leecher. I think you'll find this to be far more beneficial to the leecher than your average IRC Joe.

mIRC isn't a file server, kazaa is, ftp servers are, www servers are.

> Stop adding new
> features to the protocal and I guarentee you that in a few
> years mIRC will no longer be the leading IRC client.

What protocol are you referring to? IRC? DCC? I honestly cannot see people changing IRC clients just because the file sending is a little slower. If someone was really determined, they would just make a script.

> Even if I
> am wrong, why risk it?

Because it's a risk worth taking.

I'm sure Khaled has better things to do than make mIRC send pirated files faster. Consider the following scenario:

- Spend time to internationalise mIRC and thus increase the spread of mIRCs userbase substantially from the increased use by non-english speakers. This substantial increase will most likely result in increased registrations, which is food on the plate.

- Spend time to make files send faster so people can get the latest copy of LOTR and Harry Potter before it comes out in their local cinema. No substantial increase in user base, no substantial increase in registrations (hey, they don't pay for the warez, why would they pay for mIRC??)... no extra food on the plate.

The choice seems obvious.

Once again, if people so desperately want a faster way to send files, script the support. If people truely feel that the extra speed is worthwhile, they'll download it. No problem. Meanwhile Khaled gets to program some more interesting features.

I agree with Pasmal. mIRC is primarily for chatting. If mIRC was to implement this, where next? Multi-user downloads? Sorry, but I think you should go to Kazaa if you want filesharing on that level. That's what it's there for. And really, your transfer speed is only going to be as fast as the slowest person's connection anyway. And tronicer, just because your idea is knocked back, or people don't agree with it, doesn't mean to say that mIRC isn't moving forward.

What excactly is so revolutionary about XMIT? so far the only thing i've read is that it doesn't require delivery confirmation (or something like that).

However, when you type /fsend on (you have to be the one who sends), this confirmation isn't needed anymore, and mIRC will just keep sending packets, regardless of any confirmation being recieved (you can even see this in the progress bar).

Or am i mistaking?

File leachers? You are worried about those?
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. Besides 'leachers' as you call them don't use IRC they use other means, such as Kazaa.

Also you are worried about the developers spending time on XMIT rather than other features?
If the developers are using an object oriented programming language, XMIT will take less than an hour to program. I know, I am a programmer myself. Last I checked an hour is not a lot of time.

Script it?
Ok, so either one programmer codes it in or every one who wants support needs to script it. Also, what about people who odn't know how to script?

And yes, RFC date does matter. Because numerous other RFCs have been released announcing additions to the IRC and CTCP formats. So mIRC is going to ignore the new RFCs and consentrate on the old one?
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.

Why to do it?
* Will only take an hour to program
* Will allow support for newer clients
* Will comply with the newest RFCs
* Will save scriptors time and give the feature to people who don't know how to script.

Why not to?
* Will take time away from other project - not true unless you consider an hour a lot of time
* Will allow leachers/pirates to do faster transfer - true but it will also allow legitimate users to do it to
* 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?

> 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.

>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...

You hardley ever used IRC to transfer files? Let me guess, is file transfers on IRC too slow?
Why do you even comment on this subject if you never send files over IRC?

>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.

You don't have to look at it. Just stay away, it's easy. And why should these warez-junkies stop us other from having the latest/best features? I think you should use your energy to get Kazaa off the net. :P

>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.

A scripted file transfers would never ever get as fast as it would with a real programming language. Yeah, sure, it could be made with a dll. But that's not a point for mIRC not having it.

>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.

You said earlier that you never send files over IRC, so what do you know?

>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.

I still don't see how it hurts you? And why are you saying "we"? Who are you speaking for? And why are you happier if they send files over IM? What's the difference for you?

And again, why are you fighting so hard if you never even send files over IRC? I really want to know that!

>And by your own logic, the best thing with mIRC not having
>a monopoly on IRC clients is your ability to go use a client of
>your own choice. You can easily stay away from mIRC if
>you don't like the way it's heading.

The problem here is that there is always 2 clients involved in a file transfer. So even if i change client, the other client i'm sending to or receiving from will probably be mIRC. Or are you saying that i should send files to myself? Or telling everyone, i want to send a file, to change client?
And yeah, you too could easily stay away from mIRC...

/me noticed how none of the XMIT guys responded to Spola's post, why? Because he just proved XMIT useless.

And the other issue you brought up, IPv6, well mIRC doesn't support IPv6, so having support for receiving a request from an IPv6 client (which it will have to deny since there is no way mIRC can establish the connection) is utterly stupid. So great mIRC can now receive a DCC SEND request from another user... but it can't actually get the file. Yea I definately think XMIT is great! I mean it is DCC SEND with additional problems, and who doesn't want more problems???

As for other clients not supporting DCC SEND, just because they added XMIT didn't mean they had to remove DCC SEND, if they did that was their choice and not mIRC's responsibility to offer a solution to.

> You hardley ever used IRC to transfer files? Let me guess,
> is file transfers on IRC too slow?

Nope, because I use IRC to *shock gasp* chat and on occasion exchange pictures... though typically most people these days have a page and they just say the URL. The only other file sending that I do (or, well, used to do now) is sending scripts to people or them sending the scripts to me to check. And as most scripts weigh in at only a few kb, speed is of absolutely no real consequence.

> Why do you even comment on this subject if you never
> send files over IRC?

a) This subject is related to mIRC, so I'll comment.
b) I did not say that I never send files using mIRC. I said I hardly send files.

> You don't have to look at it. Just stay away, it's easy.

Leeching affects IRC networks in general. How many file server bots are online at the moment? How many advertisements are being spurted around giving away the latest fserv trigger? Heaps. I may not _see_ the difference but it will be noticeable in terms of performance of the network.

> And
> why should these warez-junkies stop us other from having
> the latest/best features?

Compared to the existing DCC system, it's not much of a step up. There are pros and cons to using the latest features and in this case it is IMHO that the feature is not sufficiently beneficial to justify it being implemented into mIRC, especially when it can be script. Also, best is such an opinionated word, whats best for one is not the best for another, especially when put in a context, and hence does not provide a valid reason for the promotion of the feature.

> I think you should use your energy
> to get Kazaa off the net. :P

Then they'd all go to mIRC and I'd be doomed :P

> I still don't see how it hurts you?

Network performance degrading from the bots, the spam from advertising triggers, etc... which all results from leecher activity.

And I still don't see how it benefits the average user sufficiently to justify it being hard coded in. Once again, if you're so eager, script it. Perhaps you should stop posting in this thread and just script an XMIT script and release it and let people choose for themselves. That's what scripting is all about.

> And why are you
> saying "we"? Who are you speaking for?

'We' was used as a generalisation and was not representative of any specific people.

> And why are you
> happier if they send files over IM? What's the difference for
> you?

Because then they are not on the IRC network clogging it up, nor are they building a reputation for mIRC as the 'preferred leechers software (tm)'.

> And again, why are you fighting so hard if you never even
> send files over IRC? I really want to know that!

I never stated that I NEVER send files over IRC. You've misread my posts.

> The problem here is that there is always 2 clients involved
> in a file transfer. So even if i change client, the other client
> i'm sending to or receiving from will probably be mIRC.

So the other client should still support DCC SEND. HTML enabled email clients (*shudders*) still support plain text. Winamp still supports wav files. Why should an IRC client be any different?

> Or
> are you saying that i should send files to myself? Or telling
> everyone, i want to send a file, to change client?

Or just send them a script, using convential DCC methods or by referring them to a scripting site which has the script available for download.

honds, do you have a brain defiency?


Well umm... why isn't anyone here saying "I NEED XMIT BECAUSE I SHARE PROJECT FILES OVER IRC!!!" I have yet to hear a single person argue that. So either a.) you made it up, or b.) those people think DCC SEND is just fine for their needs.


What does OOP have to do with XMIT? Is there already an XMIT lib out there? One that is free to use in proprietary software? And saying it will take one hour and that "you are a programmer myself" just made me laugh. When was it your saw the mIRC source code again? Oh wait you haven't! ANY programmer (even the worst ones in the world) can tell you you can NEVER get an ETA of adding a feature when you have not seen the base code. So don't make up garbage just to sound fancy. And if you are in fact a programmer, based on the stuff you've said, I hope I never use any of your software because with the assumptions you are making it is likely riddled with bugs, "Oh well I assume no one will ever type /invite nick %s so why check for formatting errors?" Well as the BitchX coders can tell you, yes someone will use /invite nick %s, and yes old versions of BitchX will crash. If you make ANY assumptions in coding, you are a poor coder.


Let me introduce you to a wonderful invention... it's called the Internet, you may not have heard of it I know, it's pretty much an "underground" thing, they are trying to keep word from spreading. But anyway, I'll spill the beans, see the Internet is a place where you can put a file on a place called a "website" and other Internet users can download it! So for example, this script, you could put it on a website, and all those users who can't script can go and download it! And saying everyone needs to script it is solved too... you see those people can also go and download it!


*begins laughing* are you talking abour RFC281* aka The IRCNet protocol? Those RFCs ONLY apply to the IRCNet network, and ARE NOT THE NEW IRC PROTOCOL. NO other IRCds are going to adopt those RFCs. They are a blatent attempt by IRCNet to dictate the IRC protocol for everyone else. As for the CTCP RFCs, thats even more laughable! THERE IS NO CTCP RFC.


* Will only take an hour to program - thank God you're a psychic and know this. Also it's nice how an hour is "not alot of time" If I had a free hour, I'd be very happy. I'm lucky if I have 30 minutes of free time each day, so just because you have nothing to do and an hour seems short, doesn't mean it is for everyone, ok? (Again assumptions)
* Will allow support for newer clients - It is the "newer clients" responsibility to maintain support with older clients, not the other way around.
* Will comply with the newest RFCs - Which RFCs? Give me the numbers, I just searched RFC-editor (the official RFC source) for "CTCP" it's response, "Sorry, please try again".
* Will save scriptors time and give the feature to people who don't know how to script. - Again, welcome to the internet! You can download other people's scripts!

* Will take time away from other project - as I said, I do consider an hour a lot of time, and an hour is YOUR number, not Khaled's which in my mind is equivilent to me just saying "no it will take 8 months".
* Will allow leachers/pirates to do faster transfer - How come /fsend on isn't good enough? It removes the ACKs which is exactly you "pro" for XMIT.
* IRC is a chat client - IM != IRC.

Summary:
Yea I know it's long so a quick summary, don't make up information which you clearly did, you have NO idea that it will take 1 hour, you guessed, you also claim there are CTCP RFCs, which there are not. And you even claim that the new RFC281* are the new IRC protocol, which it certainly is not! Check your facts next time, you'll sound a lot more convincing when you don't get caught in lies...

I am trying to be civil but it isn't easy. This message board is undoubtedly the least mature group and most closed minded of people I have ever met in a discussion board.


Did you ever think that I was one of those people? If you include me and my team (yes, I am a lead profesional programmer and I do have teams) then there are 10+ people right there.


I'll tell you exactly what. If the DCC SEND code is object oriented only a maximum of a dozen lines needs to be changed to support XMIT. And any one who is good enough to program mIRC in the first place can change a dozen lines in less than an hour.
If I make any assumptions I am a poor coder? That is why I get paid $20 an hour to code right? Must be. Oh and one of my contracts I currently have is to program an IRC client for a provate network. That is why I made this suggestion in the first place. My client follows the latest RTFs and the only reason I have to support SEND is because of mIRC (I have to code XMIT as part of the job).


What guerentee is there that someone who scripts it would upload it. How many hundreds of scripts are there out there that only exist on one computer?


The goal of most projects is to provide the most functionality without imparing existing functionality. XMIT will add additional functionality and will not impare any existing functions.

* "thank God you're a psychic and know this. Also it's nice how an hour is "not alot of time" If I had a free hour, I'd be very happy. I'm lucky if I have 30 minutes of free time each day, so just because you have nothing to do and an hour seems short, doesn't mean it is for everyone, ok? (Again assumptions)" - If the programmer(s) can not spare an hour then there is no time to impliment any of the suggestions in this section of the message board. So why have this section?

* "It is the newer clients responsibility to maintain support with older clients" - I am programmer of a "newer client" and I so maintain backwards compatibilty but as such I need to maintain compatibility with clients that support XMIT too. My suggetsion to add XMIT was simply that, a suggestion. I don't even know why I have argues it so long.

* "Will take time away from other project" - my hour estimate is an educated estimate. I know it can not be too far off. I'll give the benefit of a doubt and say 8 hours (which is way more time than it should take).

[b]This is taking up way to much of my time to be worth it. I am not that loyal an advocate of XMIT to care. This is a SUGGESTION forum. I am sorry for my assumtion that you guys were mature and open enough to actualy listen to suggestions. It is people with your hostility that give internet chat a bad name.
Again I appologize for thinking you guys are mature.
This is my probibaly my last post at this forum. I am not gonna defend this further because quite frankly I don't give a damn if it is added or not so why waste my time arguing it. The only reason I have kept up so long is because members of this forum are personaly attacking me. Insults are a sign of insecurity. And no I am not being hypocrytical, I am insecure myself right now, as any one would be when attacked with such vigor.
IT WAS a FRIENDLY SUGGESTION that is all. If you guys don't want it then it is fine by me. But do not personaly attack me. I have done no harm to any of you jet this forum has harrashed and abused me.
Don't bother trying to argue, I will not argue back (I do not have the time), it will just prove my point about your immaturity.[b]

this is not totaly exact.... sometimes you'll see pause in dcc transfert, it is because mirc didn't received acks pro some packets and don't have free buffer to continue to send. with fsend on, mirc doesn't wait before sending next packet IF it has free buffer. a buffer is free if 1) it has not yet been used, 2) it has been send and the ack received. how much buffers use mirc ? for what i know it is a matter of 32k / dcc packet size of something like that or maybe it is fixed to 8 by dcc... ( i do remember this 8 limit when i did some tests but ... oh well it's been a while )

I'm attacking you because you lied! And you didn't even dispute any of the lies in your reply. I said, show me a CTCP RFC, you didn't, why? Because you lied and said one existed when in fact it doesn't.

And I think saying my response is immature just proves you're immature, it's like the 2nd grader saying "la la la la I'm not listening! Say whatever you want, I can't here you!!!" Yea thats definately a mature approach...

Congrats, you proved my point.
By the way I do admit I was missinformed. I never lied. Lying implies that it is intentional.
I would have no problem with addressing your arguments peacefully and completely if you had not decided to make it personal, directly calling me an idiot and not even considering that my estimate of an hour could be complete.
In any case no matter what I said, unless I insulted you or someone else, you do not have the right to harrass me for making a SUGGESTION in the Feature SUGGESTIONs message board. I have seen a lot of bitter and abusive people in my time, I have fired people for your attitude, but you are worse than any of them. You insult completely unprovoked.

Yes, there is no RFC (to my knowledge - I though there was, therefor I was not lying, but my refference was a memo and not an actual RFC). However, I was also not able to find DCC SEND in any RFC either. Find were that is defined, if it isn't then why does it matter if XMIT isn't either.

I doubt this was already mentioned but I don't have time to read through all the bickering. I ma not even sure if this would help at all. But I did read that XMIT does not have the packet issues that DCC has. This would possibly be able to help the growing number of 2-way Satellite users who are unable to send because of the packet size problems. I am on satellite and I can not even dcc chat, or dcc send a person. I do not want it for sending warez or even sending faster (since my satellite sends slower than dialup anyway). I would like to be able to send small shareware games, or pictures, or music files. I am not trying to jump in the arguement, like I said, I don't even know if this would make a difference. And if I knew how to script it I would, but to be honest I have no clue. Sorry just had to put in my 2 cents worth.

Scripted it would be alot slower + more features -> better :P

How about everyone getting themselves a t3 connection or whatever is the fastest internet connection you can get atm. Then your DCC will go wayyyyy up ! I'm on cable, i sent someone (also on cable and pretty close by locationwise) a rather HUGE spreadsheet (almost 10 mb) and it got there with appr. 50kb/s, according to what the DCC-Send info said. *zzzzzzzzzzzzzzzzzoommmmmmmmm !!!* For some reason I think DCC is not bad at all

Johan_NL