[ gaim-Feature Requests-1239515 ] IRC account lost on exit: same server, different ports

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[ gaim-Feature Requests-1239515 ] IRC account lost on exit: same server, different ports

SourceForge.net
Feature Requests item #1239515, was opened at 2005-07-16 14:06
Message generated for change (Comment added) made by lschiere
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=350235&aid=1239515&group_id=235

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 5
Private: No
Submitted By: L W (warp9pnt9)
Assigned to: Ethan Blanton (eblanton)
Summary: IRC account lost on exit: same server, different ports

Initial Comment:
Gaim's IRC account handling does not make any
distinction between the same server with different
ports.  The Accounts dialog allows two accounts to be
created with the same IRC server and different ports.
I can add the chat to my list for each Account.
However, I can only join one of the chats.
Double-clicking the other chat does nothing.  This
might indicate that Gaim thinks I am already connected.
 Upon client exit, only the last account created is
remembered.  So perhaps IRC accounts are distinguished
only by server name, which is incorrect.

The test case is on irc.freenode.net, where the stable
server is on port 6667, and the test server is on port
9001.  I want to help with the load testing, but I
can't be on both networks.


----------------------------------------------------------------------

Comment By: Luke Schierer (lschiere)
Date: 2007-04-20 11:01

Message:
Logged In: YES
user_id=28833
Originator: NO

As we are closing this tracker, please submit any feature request that is
still valid to http://developer.pidgin.im.  Thanks.

----------------------------------------------------------------------

Comment By: Ethan Blanton (eblanton)
Date: 2005-07-20 14:57

Message:
Logged In: YES
user_id=298616

Your summary of "clean" is pretty accurate.  Basically, it
needs to "fit in" with the other Gaim code, and it shouldn't
do anything too horrible.  I can't even begin to enumerate
"horrible" things, because previous submitted patches have
shown me that my imagination is not powerful enough.

As far as backwards compatible, I'm really only concerned
that a Gaim using user@host:port does something reasonable
when it encounters a user@host entry with a separate port
item as gaim currently behaves.  This makes upgrading Gaim
just Do the Right Thing, and people don't need to notice
what's happened.  Going the other direction is probably
impossible.

Ethan

----------------------------------------------------------------------

Comment By: L W (warp9pnt9)
Date: 2005-07-19 13:32

Message:
Logged In: YES
user_id=706287

I'm willing to at least try to understand enough about Gaim
to patch this.  But I do not know what you mean by "a good,
clean patch" and "backwards compatible with old account files".

I guess the easier question to quantify is "how old"?  If
it's just a matter of me downloading an older version of
Gaim (and GTK), and setting those up so I get old files,
then I can just keep a copy of them, and use a copy to test
in the patch.  So how old?  I don't suppose the config files
store the Gaim version anywhere to make compatibility
detection easier?

A good, clean patch, I can only begin to guess.  I would
assume that it must allow building flawlessly and no runtime
crashes in at least Windows and Linux, that the new code be
formatted like the rest, that it's a collection of diff -U
patches or a single diff -rU patch, and that it does what it
intends, and doesn't do what it didn't intend.  Beyond that,
is there a specific test suite or procedure to follow?  Or
are there any other meanings impled by good & clean?

----------------------------------------------------------------------

Comment By: Ethan Blanton (eblanton)
Date: 2005-07-19 12:12

Message:
Logged In: YES
user_id=298616

As Luke described, Gaim only distinguishes two IRC accounts
by nick and server host; therefore, if you wanted to use a
different port on the same host, you would have to use a
different nick.

I am not interested in further complicating matters by
involving the port number in this.  If I got a good, clean
patch to do so, I would accept it.  (Note that it has to be
backwards compatible with old account files!)  In my
opinion, the bug which should be fixed here is that Gaim is
apparently allowing you to create two accounts between which
it cannot distinguish; this certainly sounds erroneous to me.

Ethan

----------------------------------------------------------------------

Comment By: L W (warp9pnt9)
Date: 2005-07-17 12:23

Message:
Logged In: YES
user_id=706287

Oh, I didn't notice this had been moved from Bugs to Feature
Request.  To me, this is a bug, (albeit by design), as it
doesn't handle a perfectly valid case.  But for a real
feature request which might be pertinent, consider this.

What about the case where IRC servers allow only a certain
number of connections to a port, and therefore provide
multiple ports?  For IRC, the Server Port (SP) should handle
a range (SPR), and try from first to last, or at random or
round robbin.  Therefore, an IRC account would need to
consider SP as a string, not as a number.  UN@SN:SPR

I have not yet examined account*.[ch], so I'm not aware if
all protocols are required to handle accounts in the exact
same manner, or if each protocol has it's own account type
struct, or if all possible account values are tossed into
the account struct and only the account-specific ones are used.

If you can refer me to an archived discussion of the account
handling then I might better understand what decisions were
made and why, and how the code came to be where it is.  Thanks.

----------------------------------------------------------------------

Comment By: Luke Schierer (lschiere)
Date: 2005-07-17 12:09

Message:
Logged In: YES
user_id=28833

its acting exactly as designed.  Originally we defined an
irc account to as identified by the SN alone, which didn't
work well, because of the same sn on multiple networks.  so
we changed it to use a jabber style identification using
sn@server as the identifier.  this would require it to be
sn@server:port to identify, for what is clearly a corner
case, freenode happens to be testing new code on the same
host name but a different port.  I'm not sure what the
appropriate course of action is.

----------------------------------------------------------------------

Comment By: L W (warp9pnt9)
Date: 2005-07-17 12:05

Message:
Logged In: YES
user_id=706287

Correct, that the behavior is incorrect and will be fixed at
some point?  Or correct, that Gaim won't handle it, and
nobody plans to do anything about it?

If nobody is going to fix, then would patches to solve the
problem be accepted for review, or sumarily ignored?  I have
no build environment or patches yet, but it is annoying
enough for me to investigate.

The server and port are different.  These should be allowed
as separate accounts.  And if support is not planned to do
the proper handling, then for consistency's sake, the Add
Account should be modified to scan for the existing IRC
server name and disallow adding with a warning, so as not to
lead someone to initially believe that Gaim will handle this
properly.

----------------------------------------------------------------------

Comment By: Luke Schierer (lschiere)
Date: 2005-07-17 08:42

Message:
Logged In: YES
user_id=28833

correct, gaim can't handle that.

----------------------------------------------------------------------

Comment By: L W (warp9pnt9)
Date: 2005-07-16 14:12

Message:
Logged In: YES
user_id=706287

Sorry for double post, but I just noticed some additional
behavior.  On the buddy list were both channels with an
alias set to indicate the ports.

#channel (6667)
#channel (9001)

When I joined either channel, the last one (9001) was
displayed in the conversation window title.  When I deleted
the #channel (9001), then the conversation window title
immediately changed to #channel (6667), further indicating
that the accounts do not distinguish the ports as the
Account UI would at first seem to indicate by allowing two
entries to be created and exist.  Upon client restart, or
merely joining channels, the truth of the bug is revealed.

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=350235&aid=1239515&group_id=235

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Gaim-features mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gaim-features