First off I cannot say enough how awesome spark/openfire is!! Simply amazing… I do however have a few feature requests to throw your way (spark team), that would help with some items that users are repeatedly nagging me about. So here goes a few:
It would be very helpful to be able to transfer FOLDERS as well as files with the file transfer feature… I think that many people would agree that it would be a nice addition to an already great feature. Dragging and transferring a folder containing multiple objects would be perfect…
It would be nice if the DO NOT DISTURB status option, actually did that… Meaning if you set it to DO NOT DISTURB, spark should NOT allow message to be pushed right to you anyways… I have alot of people annoyed by that. They set it to DO NOT DISTURB hoping that it will stop people from bothering them if they are doing something important and do not want to be bothered, but the messages come right through anyways… I know you will just say to tell them to log off… but that defeats half of the purpose of the client… People WANT others to know that they are at work and at their computer, but sometimes also want to NOT get messages if they are really busy… Then spark should get them their messages when they change their status back to one of the “available” type options, kind of like offline messages. Having people log out or close spark so they won’'t get bothered is an annoyance, because half the time they forget to reopen it… Again it would be a nice feature I believe…
Having the resource policy set to always kick seems rather buggy… If you are logged into client 1 and got to computer 2 and try to log in, it DOES immediately kick the client on Computer 1, but it DOES NOT let you then log into client 2, instead it says to the user “invalid username or password”. I know a ticket was opened up to make that message a little clearer for connection errors ( I actually manually changed mine to say “Connection Interrupted, Please Re-Login”). It seems like if you have it set to always kick, then when you try to connect from another machine, it SHOULD kick the other connection, and ALSO let you log right into the new connection you are trying to establish, but it never does, you always have to try again… also, if you then manually close the new connection on pc 2 and go back to pc1 that has a screen up saying the connection was closed… and it has reconnect button there, but it does not work… if you try to reconnect, for us it ALWAYS does the same thing… being that it connects, shows all the groups, but they are all empty, and you cannot send OR receive messages, but you appear to be online… Maybe even just an option saying “Your Account is already in use on another machine, would you like to kick the other connection?” with a yes or no choice, then if they choose no, nothing happens, if they choose yes, then it closes other connection, THEN offers them the login screen to attempt the login, it just seems like a better approach to the feature you have, since the first login attempt does not actually ever work with that policy set up (always kick)…
#1 might be tricky. I doubt you could really handle folders directly. Having to deal with folder names and recursive subfolders, etc would become a whole new protocol. But perhaps using some container before and after transfer (like Zip or Tar or whatever) would work. zip may not be the best directly since you need to have external tools to do that, but a jar file (which is basicly a zip file) has native Java tools that could accomplish that. Then clients who do not understand the whole “Send Directory” thing will at least get a file that can be opened with WinZip then.
http://www.igniterealtime.org/issues/browse/SPARK-573 is about font size… do you have a different one? You might be right though… If it has been marked somewhere as fixed, it might actually still be partially not working… I will search jira issues to see if I can find it…
it must be a xmpp standard to behave like that. And i think Do Not Disturb literally means a request not to send messages and not a blocking feature. It’'s just one of a presence statuses, which are not ment for blocking (or other stuff) messages, just for information. So DND should stay as it is. So, you can only suggest some unique (Spark only) feature like “Block messages”, maybe this will be indicated by some other icon in roster. But i dont like this. DND is ok for me, and there always could be a matter too important to wait for person to become Available again, so everyone should be reachable. The other thing is to “fix” your users to understand that status and to respect others.
Just imagined me turning Block and forgeting about this and my boss trying to contact me for a day
wroot: I know what he is talking about. AIM, and others, have support for this feature and it wouldn’'t violate the protocol in any way. The idea would be to just have an interface option that hides the messages until returning from away. You could even have the system try icon give a message count. Or like with AIM, when you go away and hide new messages, it leaves one window open that just updates with a list of received messages. And of course, its optional. So if you are afraid of ignoring your boss for 4 days, dont turn it on
My guess is he is looking for an AIM feature, and since so many people have used AIM I imagine there are a good number of people who have used this feature before.
But it’'s not normal for DND feature to block/stack messages i think. I havent noticed such behaviour in other xmpp clients or ICQ. So it must be something else.
you mean Pidgin havent ever tried to do that with it. will try at home. But maybe client should send something to the sender, like “This user has blocked incoming messages. Your message will be received when he(she) get Available”