Opened 11 years ago

Last modified 11 years ago

#5568 new defect

XMPP screen name and domain should not be in separate fields.

Reported by: resiak Owned by: deryni
Milestone: Component: XMPP
Version: 2.4.1 Keywords:
Cc:

Description

I'm pretty sure that most people think of their jid as one string, foo@…, not as separate screen name and domain components. What's stopping us blowing away this user split?

Attachments (1)

jid-text-boxes.gif (7.9 KB) - added by jd49 11 years ago.
6 different possibilities

Download all attachments as: .zip

Change History (13)

comment:1 Changed 11 years ago by deryni

I think it makes things like #2500 harder, not that we handle it correctly at the moment either, but last time I tried to understand how we should correctly handle all of that my brain hurt.

comment:2 Changed 11 years ago by jd49

There's been discussion about this for a long time. Until now, only two options have been discussed: 1) one text box for the whole JID: This confuses people who don't know what JIDs must look like. 2) 3 text boxes in 3 seperate rows: confuses people who try to type their full JID into the first text box.

I suggest that we put the 3 input boxes in one row, as shown on the image i posted. Note: This image is not a screenshot of an existing implementation.

comment:3 Changed 11 years ago by deryni

That has been suggested before somewhere, I'm not a huge fan of it, though I don't much care one way or the other in general. I do think that simultaneously helps and hurts the use case in #2500 though.

comment:4 Changed 11 years ago by deryni

  • Owner changed from nwalp to deryni

comment:5 Changed 11 years ago by jd49

I thought this might be a compromize between showing JIDs as one string and providing 3 independent text boxes

comment:6 Changed 11 years ago by jd49

If we use 3 textboxes, we can easily find out what slashes (in the ressource) and what @ signs (in the username) need to be escaped. If we use one text box, we'll have problems with JIDs like "abc@…/abcd@…/abcde". If we use 3 different rows, people will try to put their whole JID in the user box or put their server address in the Domain box.

I think use case #2500 is very rare. I know that XMPP @ characters in JIDs. Therefore, XMPP implematations should support it.
Nevertehless, I think JIDs like abc@…@example.net/abcd should not be used since they are very confusing. If users who have such JIDs are confused, it's the JID which is confusing, not the GUI.

comment:7 Changed 11 years ago by jd49

Ooops I made a mistake...

In my last post, I meant "I know that XMPP *allows* @ characters in JIDs."

comment:8 Changed 11 years ago by resiak

NB. I wasn't suggesting removing the separate Resource field.

Username: [foo@livejournal.com             ]
Resource: [ImTooLameToChangeMyResource     ]

In the "i've got an at in the bit of my username before the at sign delimiting the server" case:

Username: [foo@broken.com@morebroken.co.uk ]
Resource: [MyHeadJustExploded              ]

then just split at the final at, since @ isn't valid in domain names. What am I not understanding here?

comment:9 Changed 11 years ago by jd49

resiak: I wasn't shure whether you suggested to remove the resource field or not.
The problem that I mentioned (a@b/c@d/e) does only occur if we use 1 field.

Changed 11 years ago by jd49

6 different possibilities

comment:10 Changed 11 years ago by jd49

I changed the image that i posted before. Now it shows 6 different possiblities that we could discuss now.

comment:11 Changed 11 years ago by spike411

I'd suggest removing Resource field from (non-Advanced) settings entirely. At least ejabberd and Gmail (and possibly other servers) can assing (random) resource strings when client provides no resource on its own, thus there is no risk of resource conflicts and you get a bit simpler UI.

comment:12 Changed 11 years ago by deryni

Any server that requires a resource MUST (per XMPP RFC) be able to generate a resource for the client. So yes, I agree that moving the resource field away from the username/domain/password triple is a good idea. Moving it to the bottom section is likely easier then moving it to the Advanced page (given the way the code is set up) but I think I agree that the Advanced page is a better place for it.

The changes in patch #5565 are (at least in part I believe) needed before we can really do this correctly (that is allow for an empty default resource). I am intending to apply that patch and will attempt to take care of as much of this as is reasonable then.

Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!