Community
Participate
Working Groups
Similar to how we support /join, we should support /server to allow people to connect to multiple IRC servers.
Setting target milestone to 1.0.2.
I'm interested in working on this bug on Eclipse Bug Day (July 27 2007)
It's all yours Cagatay. Thanks!
Created attachment 74846 [details] "/server Command" patch
usage: /server [<user>@]<ircserver>[:port][/<channel>,<channel2>,...] [password] (like ECF wizard style)
Created attachment 74847 [details] "/server Command" patch Just removed an irrelevant TODO comment in the code.
(In reply to comment #6) > Created an attachment (id=74847) [details] > "/server Command" patch 1. Nick should default to whatever you're using right now (in whatever server you're typing the command) instead of generating some random name. I think the IRC wizard's now doing that too actually, from what I saw when I did CVS update last night? In that case it should default to System.getProperty("user.name") (or unless you feel like iterating over current IRC IContainers and getting other nicknames that way). But that's a separate issue anyway, per se. 2. Use a constant for "ecf.irc.irclib". I don't think we have one...make one. ;)
Created attachment 74853 [details] "/server Command" patch Handled both items in Comment #7. 1. Nick defaults to whatever you're using right now (in whatever server you're typing the command) 2. There's a constant for "ecf.irc.irclib".
Cagatay, your newest patch from comment #8 breaks API (IChatRoomCommandListener). I don't know if you were aware of it or not, but well, it breaks API. ;p I'm not sure if we want to do this. Bringing Scott into the discussion.
I'll weigh in here. First, I want to say to Cagatay that your work on this bugday bug and others is **very** appreciated...none of what follows is meant as a criticism of you or your contributions (which have been terrific)...it's just that as an Eclipse project past 1.0.0 we now need to follow some rules for making changes so that people building upon our work can have some predictable behavior across versions. These points should have been made earlier (by me...sorry about that), and further I probably should have asked that people have a look at API changes/additions rules recently created here http://wiki.eclipse.org/ECF_Ganymede_Roadmap. On breaking API: I haven't had a chance yet to look at the code for this contribution, but in general we don't want to immediately (i.e. before 2.0.0 milestones) make changes that break API. So if we jointly deem this feature important enough then we can schedule it for later addition (i.e. for ECF 2.0.0 milestone), if we can't find a way to introduce it without breaking API (which would obviously be preferable). On this feature: I should have made this point earlier (i.e. on Friday), but I didn't think about it carefully enough at that time, and I have been traveling this weekend. I'm not sure I agree that this feature (support of /server command) is really needed. That is, we have the ability to use the wizard UI for connecting to other servers, and although I understand that some people like the IRC /commands, support of the /server command seems relatively esoteric to me. Are there people/use cases that depend upon /server support specifically? Further, I think we *can* improve the UI relationship between the connection dialog and the UI for both the messages view and the chat view...and if these two merge into one e.g. bug 181507, then all the better. But I'm not sure if having support for /server is really necessary. Let me know if you think I'm wrong on this.
I'm inclined to mark this resolved/wontfix. Cagatay please reopen if you have thoughts contrary to comment 10.
closing
