Closed Bug 73257 Opened 24 years ago Closed 20 years ago

implement DCC FILE and CHAT protocols

Categories

(Other Applications :: ChatZilla, enhancement)

Product:
Other Applications
Component:
ChatZilla
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
Future

People

(Reporter: gwalla, Assigned: bugzilla-mozilla-20000923)

References

(
URL
)

Details

DCC file transfer is a commonly used method of exchanging files over the Internet in a peer-to-peer fashion. A transfer is initiated by sending a "DCC SEND" CTCP request containing the filename of the file to be sent, the IP address of the sender, and an open port on the sender. Actual file transfer is through a telnet connection to the given IP and port.
I am aware of DCC and would like to implement it. The problem is that I don't think we have any way of creating a server side socket from JavaScript. Accepting a DCC is another story, and something that could be done with what's available. I had not seen the DCC spec, thanks for pointing that out. Accepting and marking future. I'm not sure when this will get imeplemented, but it's something I'll do eventually, if noone gets to it first. I'm also adding DCC CHAT to the summary, they would likely share a large amount of code.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Summary: [RFE] implement DCC file transfer → [RFE] implement DCC FILE and CHAT protocols
Target Milestone: --- → Future
Okay. I was going to file a separate bug for CHAT, since the frontend would be so different, but I won't bother now that this bug is for both. Thanks!
Filed RFE for ability to open server sockets with local JavaScript as bug #74045. MArking dependency.
Depends on: 74045
*** Bug 80606 has been marked as a duplicate of this bug. ***
Depends on: 92928
I'm just wondering if JSLib on mozdev would help with this. Specifically these tcp/ip functions http://www.mozdev.org/source/browse/jslib/libraries/network/socket.js?rev=1.1&content-type=text/x-cvsweb-markup
Nope. That file came from ChatZilla in the first place (jsirc is the name of the irc library created for ChatZilla.) Bug 92928 keeps us from creating a server side socket in javascript.
Blocks: 132267
Remove myself from QA of 33 open Chatzilla bugs and change to default QA contact, since I have no way to verify these easily. Still no working Mozilla on my primary platform and it doesn't look like it will happen anytime soon. :(
QA Contact: mozilla → samuel
*** Bug 150215 has been marked as a duplicate of this bug. ***
I tried chatzilla only for 1 hour and already had cause to need this feature.
Summary: [RFE] implement DCC FILE and CHAT protocols → implement DCC FILE and CHAT protocols
Seeing this bug is closing up on it's 2 year birthday, mayby we could at least get the quick "only recieve DCC" feature implemented? I'm starting to tire of having to explain to 10 people a day why I'm not able to recieve their DCC sends. :D DCC Chat and send files would be nice too, but the lack of DCC recieve is IMO the current largest gripe I have with chatzilla. It's the last stepping stone IMO to make chatzilla a "real" IRC client that doesn't nessesitate you always having another chatclient at your disposal to get basic functionallity. Please implement this ASAP :) /me crosses his fingers and hopes the *magic* word works ;)
Stefan: feel free to implement it.
I'm sorry if this did not send... I'm really not sure how to submit in bugzilla... I think (Acknowledge::I know very little about programming) that if people took the protozilla project on mozdev and talked to people who work on bitchx or any other textual irc client that would be a start because if you use protozilla to add the protocal (stack/layer/???) to mozilla and get/implament something from a textual irc client (opensource) then that may be a start... after... maybe people could make a phonex-like (meaning executeable and small) irc client that comes as part of the mozilla suite so when you type irc://irc.foo.bar.net/ a new tab/window would popup/open and would say "loading" with a loading bar... and then the phoenix-like irc client would be called and ....??? I hope people understand what I am trying to say....
Now that server side sockets are in the trunk, what needs to be done to get this implemented?
All it needs now is for someone to do the coding. :-)
Holy **** its been almost three years! Thats crazy, and why very few people use chatzilla on the IRC servers. All I wanted to do was send a screen shot of chatzilla to someone though chatzilla, and I couldn't do it. That's sad for me and others who would very much like to use chatzilla as a primary IRC client. :(
Just to let people know, I've got DCC Chat in a mostly working state now. DCC Send needs some work on the connections first to allow for binary streams, but it's getting there.
Assignee: rginda → silver
Status: ASSIGNED → NEW
Right, I've put up a DCC Chat test version of ChatZilla, based on 0.9.60, that has /dcc-list, /dcc-chat, /dcc-accept, /dcc-decline and /dcc-close commands implemented (it.s 0.9.60d). There is a way to go yet, but the basic functionality is there. Currently known about issues include: - Can't tab-complete nickname in a DCC Chat view. - Sometimes get (null) in connected/disconnected messages instead of an IP when you (ChatZilla end) initiate the connection. - The URL in the header is completely bogus. - The only text that can be sent is normal, and /me text. Other things about this implementation: - There is a 10 second security delay between a DCC Chat request arriving and being able to use |/dcc-accept|. You can always use the command with a nickname (or unique prefix of the nickname). - If you are behind a NAT/gateway, you won't be able to start conversations. If you want to experiment with forwarding ports on your gateway, you may change the "local" IP address ChatZilla uses by doing this (with your gateway's public IP): /eval client.dcc.localIP = "129.168.0.1" There's probably many things that don't work yet, or don't work right. If you find something really broken, the best thing to do is to tell us on irc://moznet/chatzilla.
[INFO] Chatzilla 0.9.63b [Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040206 Firefox/0.8] I don't feel it's necessary to file a new bug for so little but the version above displays the following help message for dcc-list: [USAGE] dcc-list [<type>] [HELP] Lists the currently known about DCC offers and connections. This may be limited to just "chat" or "send" using the |type| parameter. The currently known what?
(In reply to comment #18) > [USAGE] dcc-list [<type>] > [HELP] Lists the currently known about DCC offers and connections. This may be > limited to just "chat" or "send" using the |type| parameter. > > The currently known what? Well, it makes sense as it is, but you can drop 'about' and it means pretty much the same.
Removing "about" would result in better grammar.
Is it just me, or is this fixed?
(In reply to comment #21) > Is it just me, or is this fixed? Depends on the criterion for 'fixed'. Yes, we can send files and chat using DCC now, but there's no UI at all, and it's useless at telling the user what's going on. Whether this bug should stay to cover those usability issues, or be closed and have other bugs filed isn't my call, it's up to the reporter really.
> Depends on the criterion for 'fixed'. Yes, we can send files and chat using DCC > now, but there's no UI at all, and it's useless at telling the user what's going on. > > Whether this bug should stay to cover those usability issues, or be closed and > have other bugs filed isn't my call, it's up to the reporter really. Oh, reporter?
i guess we should keep it open as a tracking bug. while dcc is now supported, it is still not top quality, as expected form mozilla suite/addons. now for a couple of suggestions: why different commands, if SEND, GET, CHAT, INFO (and perhaps CLOSE, REMOVE, etc.) could be arguments of /dcc command? it is a logical way to do and other irc clients do it that way. also, with dcc file protocol, where do we stick with downloads? what about the difference in downloaded files handling in mozilla and firefox (dedicated folder in fox, last selected in moz)?
(In reply to comment #24) > why different commands, if SEND, GET, CHAT, INFO (and perhaps CLOSE, REMOVE, > etc.) could be arguments of /dcc command? it is a logical way to do and other > irc clients do it that way. Because with separate commands it's possibly to actually explain how to use each one separately in the help. I also think overloading one command to do many, quite different, things isn't nessessarilly *good*. > also, with dcc file protocol, where do we stick with downloads? what about the > difference in downloaded files handling in mozilla and firefox (dedicated folder > in fox, last selected in moz)? When you accept a file, you get a file browse dialog to pick where to save it. This could be 'improved' to allow all files to be automatically downloaded to a single folder (though I personally hate that feature of FF :) ), though trying to use the host's (Moz or FF) prefs for it is asking for trouble.
i do not buy the help reason :) regular irc user would not know about separate commands in a client, so he or she will try /help dcc and see (let us not go into what happens, if only /help is wtritten, because this is not realted to this bug:)) all the dcc related commands anyway. also, the preferred mettod (shared in all clients) is to answer a DCC SEND request with DCC GET (or close; mostly, users just let unwanted dcc sessions to time out) and CHAT with CHAT (or close). here dcc-accept could be kinda nice as universal response, but as a command, it is hard to type. ok. it could be aliased/scripted but still. as you see, i am not dissing the choice of commands, it is purely for similarity with other clients, which leads to ease of use. also, your reply about prefs reminded me of some other thing. for security reasons, having chatzilla its own totally separate prefs file would be really good idea. but, thats another bug altogether:)
(In reply to comment #26) > i do not buy the help reason :) Then many a single /dcc command should have been suggested when I was implementing this. :P > ... it could be > aliased/scripted but still. as you see, i am not dissing the choice of commands, > it is purely for similarity with other clients, which leads to ease of use. Similarity with other clients is separate from ease of use. Eventually, the plan is to have things the user can click to accept/decline DCC offers, right there in the message itself. The commands are there for people who can read help. :) That's my view, anyway. It's also occured to me that this bug is mailing a lot of people, so I'm going to make it FIXED, and open bug 251983 for remaining DCC issues.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Sorry I took so long to respond. I agree with keeping this resolved FIXED and using another bug for UI and such.
Product: Core → Other Applications
You need to log in before you can comment on or make changes to this bug.