ejabberd - Comments for "ejabberd on WinXP, Pandion, shared roster groups, & presence"

Re: Obvious misunderstanding

mremond — Mon, 01 May 2006 16:08:57 +0000

I wrote my answer to work out and eliminate the misunderstanding, even it would have increase the misunderstanding.

I think however that we are now on the page :-)

I will keep you informed of our progress on the shared roster problem you have exposed.

Thank you !

--
Mickaël Rémond

Re: Obvious misunderstanding

sander — Sat, 29 Apr 2006 10:28:32 +0000

fseesink wrote:

I was trying to get the point across that this needs, if nothing else, to be documented in plain sight so others do not begin using ejabberd, only to want to throw it out the window because of something that was a known problem. If admins go in with eyes wide open, they know what they're in for.

You write "this bug will (however ;-) be solved in the next release. We had scheduled it before you send your flood of messages." Fantastic! How about putting that out someplace where people might actually SEE it. To be clear, it's not for me (I already know it's an issue obviously). But to cut down on even more...how did you put it..."flood of messages."

Quote:

As a user of ejabberd, I'd like to see it used a great deal more. So I try to help, in what way I can, to make it a better program.

Quote:

It was also to say, "If this is not a priority, that's fine. But you might want to put a notice up so others are aware and don't keep nagging you about this."

A simple, "We're working on it" would've been enough to keep me from going further. I'd know you were on it, and any further writings would just get in the way.

Have you thought about contributing an entry to the FAQ about the issue (and maybe others)?

Obvious misunderstanding

fseesink — Fri, 28 Apr 2006 22:02:32 +0000

Mickaël,

I appreciate the links. I am well aware of Eric Raymond's writings. I have/read "The Cathedral and the Bazaar" among other things. But it's quite clear signals have crossed and there have been some misunderstandings. Your reply shows I have done a poor job of getting my point across, so bear with me here.

1. Yours is the first actual written reply to anything I've posted for several weeks, be it here or in Bugzilla. This includes a simple, "we see it" flag. TRANSLATION: no feedback = no clue whether anyone is even paying attention. The only responses I could get was by logging into the ejabberd conference room and talking with folks there, including badlop, sander, and even alexey. If there are transcripts, check them out. Might help clarify my position. [HINT: Note the change on the front page where it now clearly warns newbies that shared rosters have issues.]

2. In connection with #1, note I was not writing "whah whah whah! Fix my problem now!!!" I was trying to get the point across that this needs, if nothing else, to be documented in plain sight so others do not begin using ejabberd, only to want to throw it out the window because of something that was a known problem. If admins go in with eyes wide open, they know what they're in for.

3. Regarding that "flood of messages", you might notice I wrote up an extremely specific test case, one that is reproducible EVERY TIME. And if you'd bothered to pay attention, you might realize that this wasn't something I could slap together in 5 minutes. As a user of ejabberd and fully aware and appreciative of the effort that Alexey & co. put into the software, I spent an inordinate amount of time testing and retesting to absolutely nail down where the issue was, complete with traces. This is what a developer usually wants...a reproducible bug they can follow and get to the heart of. No offense, but this wasn't exactly "Hey, your sh*t's broke. Fix it."

4. You might consider following your own advice. Your snide comments like "someone coming and taking for granted that developers have to work as soon as possible on his own particular problem" (something I never stated, meant, or in any way implied...the fact I spent a few nights building the test case was done to SAVE Alexey time, not waste it), "getting people to think that they will not read any more posts of the rude demanding person" (care to point out exactly when I was rude?), the whole "flood of messages" bit, and "to make the nice software you are using" aren't exactly nice. If you wish to build a community, it's also not wise to insult those trying to help.

ejabberd is a free, open-source project. It's done for whatever reasons Alexey & everyone else involved chooses to do it, and those of us who use it are greatful they've chosen to share it. And it's a great little piece of software.

But like any software out there, the ecosystem isn't just made up of the developers. If no one uses it, there's not much point. As a user of ejabberd, I'd like to see it used a great deal more. So I try to help, in what way I can, to make it a better program. Maybe my writing isn't as succinct as you'd like. Then again, maybe yours is too succinct (as in lack of documented issues you're working on) for me. But my intention wasn't to give grief. It was to nib in the bud the typical comment from some developers who want exacting, specific instructions on how a bug shows its ugly little head. And that's exactly what I did. And after the initial post, as I found other information, I posted that as well, if for no other reason than to hopefully prevent others reinventing the wheel. It was also to say, "If this is not a priority, that's fine. But you might want to put a notice up so others are aware and don't keep nagging you about this."

A simple, "We're working on it" would've been enough to keep me from going further. I'd know you were on it, and any further writings would just get in the way.

Regardless, thanks for responding here. I realize you likely didn't see the conversations on the conference room, so that you took the time to respond, thank you.

Hello, We hear you, but I

mremond — Fri, 28 Apr 2006 17:39:27 +0000

Hello,

We hear you, but I just wanted to remind you some small basic psychological tips on how to ask people to solve your specific problem. Bear in mind, that solving bug are a time consuming and sometime frustrating exercice.

Please, could you have a look at the following document which is explaining quite nicely how to interact in a friendly way with an open source communities:
How to ask questions the smart way

Some sections are particularly interesting:
- Volume is not precision
- Don't flag your question as “Urgent”, even if it is for you
- Courtesy never hurts, and sometimes helps

We hear you, but it is not very pleasant for the participants of a community to see someone coming and taking for granted that developers have to work as soon as possible on his own particular problem. It could even have a counter-effect, getting people to think that they will not read any more posts of the rude demanding person.

That said, this bug will (however ;-) be solved in the next release. We had scheduled it before you send your flood of messages.

Do not take any offense but simply try to get into the shoes of people working hard, nights and week-ends included, to make the nice software you are using.

--
Mickaël Rémond

ejabberd 1.1.0 on Windows, shared rosters, presence problem

fseesink — Thu, 27 Apr 2006 01:40:54 +0000

Sorry to disappoint, but I finally got around to testing the latest ejabberd 1.1.0 binary for Windows, and I am sad to report that the presence problems as described in this thread and in the related bugzilla report (#233) persist. Renaming a user on one's roster when it is a shared roster causes absolute havoc to presence notifications. This is simply not right.

I had very high hopes that 1.1.0 binary contained the fix(es) needed. I was asked to test the SVN version, which I did not have the time to download/compile/build/etc. But that was BEFORE the release of 1.1.0. So I'm guessing whatever I would've found in the SVN version likely would not have worked either.

It is very clear that the subscription settings are just plain wrong with regard to shared roster entries. Why do they persist in showing 'none'? Anyway, I need to find a resolution to this. It's really a pain in the butt, and it's quite the show-stopper for anyone who wishes to use shared rosters.

This is a nightmare from an admin's point of view, as it makes the shared roster feature more than useless. You're better off simply NOT using this feature at all. Anyone attempting to do the most simple of things (renaming someone on their roster to a name they prefer) suddenly loses presence of that user, as does that user of them! That is NOT a minor issue.

ejabberd on WinXP, Pandion, shared roster groups, & presence

fseesink — Thu, 13 Apr 2006 21:35:25 +0000

I have logged this as a bug in BugZilla here:

http://www.jabber.ru/bugzilla/show_bug.cgi?id=233

Note I have also made the traces available there.

To finish the whole

fseesink — Thu, 13 Apr 2006 20:50:17 +0000

To finish the whole mod_vcard_ldap coverage, I decided to disable any form of vcard by commenting out the appropriate lines in the ejabberd.cfg file. Then I reran the tests I originally described.

Of course, with mod_vcard* disabled, users are no longer able to search for others, NOR are they allowed to change their nickname in their profile. Thus all users appeared by their JIDs. But it all did work well. While not the long-term solution, it prevents what I found to be the cause of all my nightmares.

Digging further, I believe I have discovered that ejabberd is doing something incorrectly when a user has a NICKNAME set in their profile. First I reset the config to what it was with mod_vcard enabled. Redoing the steps I originally posted, I used the console window in Pandion (hit F12) to capture the XMPP streams from EACH login/logout session of both the 'allen' and 'frank' users. These traces are available if you'd like.

Analyzing those streams, all seems normal up through 'frank' setting his NICKNAME to 'Frank' and sending that to ejabberd. During 'frank's next login, ejabberd sends the usual stream (which includes the roster which indicates each member has subscription=both). Then Pandion does an {iq} to get vcard data on each roster member, and ejabberd sends back a response for each user, and the profile information for 'frank@mycompany.com' including the nickname 'Frank'. Pandion then sends an {iq} set command to set the roster name to 'Frank'. ejabberd responds by sending an {iq} push packet that sets the name of the user to 'Frank' AND sets subscription=none! Well that's not right.

Even worse, when user 'allen' signs on the first time after that, ejabberd sends 'frank' first the {presence} packet for 'allen' with avatar information, followed immediately by a second {presence} packet indicating 'allen' is 'unavailable'!!!

And oddly enough, the same occurs from 'allen's perspective. That is, as 'allen' signs on, ejabberd sends to allen first a {presence} packet with 'frank's avatar information, then sends another {presence} packet indicating 'frank' is 'unavailable'!!!

Please note at NO time do either client send a {presence} packet indicating they are 'unavailable'. This is purely generated by ejabberd.

Note from the steps above that, upon the second login by user 'allen', the name 'Frank' appears in the roster. Looking at the XMPP stream, the same thing happens as did for user 'frank'. That is, 'allen' receives the roster. 'allen' requests vcard data. ejabberd responds with packets for each user, and for 'frank' it includes the profile information. 'allen' then does an {iq} set command to set the roster name to 'Frank', and ejabberd responds with an {iq} push that not only sets the name, but also sets subscription=none!!!

Please also note, as I already indicated earlier, that via the ejabberd web admin, it seems that although all users are on the same server, their subscription appears in the web interface to be set to 'none'. Considering that when a user signs on, the stream shows they are receiving the roster with each user's subscription=both, and then throw in how ejabberd sends an {iq} push that then changes it to subscription=none, there's definitely some goofiness in how ejabberd is storing subscriptions as well.

Anyway, hopefully this will give the ejabberd team enough data to work with. Again, if you would like the traces, let me know. I will keep them handy and can either email them or post them somewhere for you to download.

[NOTE: I had to use {} instead of greater-than/less-than due to Drupal's formatting limitations.]

ejabberd on WinXP, Pandion, shared roster groups, & presence

fseesink — Thu, 13 Apr 2006 01:43:23 +0000

Just wanted to add some new info to this thread. As I mentioned, this configuration does external authentication via LDAP, which works just fine. So decided to do some more Googling.

End result: learned a little about mod_vcard_ldap. Though there is VERY little documentation regarding this, I was able to re-run my test above with a slight change to my ejabberd.cfg file; namely, I replaced the line

{mod_vcard, []},

with

{mod_vcard_ldap, ["jud.mycompany.com"]},

[NOTE: As we also had DNS entries setup for our previous jabberd 1.4.x install which included 'jud.mycompany.com', I thought why not try this. Maybe the issue was that with LDAP used for authentication, using the internal storage for vCards was "confused" or something. Besides, vCard user searches never worked before.]

And sure enough, all of a sudden doing vCard user searches in Pandion worked like a champ!

UNFORTUNATELY, the issues mentioned above actually only got WORSE. You see, the issue appears to be with respect to the NICKNAMES. I say this because the original setup (LDAP authentication, basic vcard support) works just fine UNTIL someone gets the bright idea to modify their profile and change their nickname. Only after a user does this does presence get goofy.

With the above adjustment to use mod_vcard_ldap, all of a sudden EVERYONE has a nickname. This appears to be due to the fact that mod_vcard_ldap sucks in various attributes from your LDAP tree and maps them to the various vCard entries. And, as quickly witnessed through the web admin interface, if you have shared rosters setup, then the first time you login, every single person on those shared rosters gets a nickname. And the end result of this? You can't see ANYONE!

So now magnify the logout/login 2x since the you've changed your nickname thing before things settle out. It's absolutely awful.

And based on a rudimentary glance at the XMPP stream, it does appear that presence is not being sent when a user signs in. I really need to go read the RFCs/JEPs on this, but not sure if the client is supposed to request the roster, then begin requesting presence of each member on the roster, or the server is supposed to push presence at the client automatically based on the roster stored in the server. The latter seems more logical, but who knows.

Anyway, this hopefully will give the ejabberd folks enough information to work with. But as it stands now, shared roster groups in ejabberd are extremely frustrating.

ejabberd - Comments for "ejabberd on WinXP, Pandion, shared roster groups, &amp; presence"

Re: Obvious misunderstanding

Re: Obvious misunderstanding

Obvious misunderstanding

Hello, We hear you, but I

ejabberd 1.1.0 on Windows, shared rosters, presence problem

ejabberd on WinXP, Pandion, shared roster groups, & presence

To finish the whole

ejabberd on WinXP, Pandion, shared roster groups, & presence

ejabberd - Comments for "ejabberd on WinXP, Pandion, shared roster groups, & presence"