Spark SSO and Unread Messages

Here are some features that I think are important to add to the next Spark update

  1. Spark SSO improvements:
    Currently, SSO do not really function as SSO since users still have to enter their passwords at initial sign on or when their password has expired or changed. This is very problematic when you have to deal with hundreds of users that you want to force to log on. A feature in the default.properties might be a good remedy for this problem that is a topic of discussion for years now. I do not think that one should force users to remember to sign on to a service when this can be implemented in the software. Users can forget to sign in or just disregard signing in. Suggestions of implementing policies to force them to sign in on an IM service is plain ridiculous.

  2. Unread Messages:
    There is a problem when a user who is away receive messages and is unexpectedly logged out after his Windows session ends. When this user logs back in, there is no notification that they missed any messages.
    There should be a fix that allow users to see messages that they’ve never read. Lots of messengers does this so I know that it is possible. Probably by detecting that the focus was moved to that window or if the user clicked on the window to open the message. If the user never interacted with the message window after a message arrives, that message should be marked as “unread”. When the user logs in again, the message window should pop up in the task bar blinking and so alerting him of unread messages. Many users missed important messages because of this “bug”.

Unread Messages: Are you talking about XEP-0184, message delivery receipt support? This has been discussed before here:

XEP-0184 is a pure client side feature as I understand and would be a great addition to Spark/Smack. Now that Florian added support for this into SMACK, it became a lot easier to add to Spark.

Thanks Martin. I had to do some reading on XEP-0184 here http://xmpp.org/extensions/xep-0184.html before I could answer your question. I think this is exactly the problem I am refering to. I hope this issue is resolved soon.

Moving into SSO with Openfire and Spark from the dev point of view requires some deep knowledge in MS wounderful world of AD. I am sure they managed to have subtle differences between different releases of Windows Server 200x x32/x64. No easy stuff there. Looking into http://community.igniterealtime.org/docs/DOC-1616 does not enlighten me to much and I am sure the same applies to my dev team (that has a diifferent focus, namely the IM gateway and file transfer). You need to be a person with some detailed know how of AD administration to do grasp it.

If your company requires this feature: Please hire a developer and help the project. Get some students from university. But please: Do not raise feature requests. No one is waiting for a good advise what should be next. Sorry, if this sounds rude.