Hi-

First, let me just profusely thank the developers for releasing this app. I’d been looking for a jabber client for my iPhone (or even a web-based one) that supports MUC over https for several years no to no avail. So when your application came out, it made me deliriously happy.

I’d like to request three features, some probably being harder than the others:

1. All of the desktop clients that I have used know how to cope with the IRC-like shorthand of “/me {something}” being displayed with the handle of the person sending the message replaced for “/me”. For example, if I type “/me goes to the store” all of the clients show the message as saying “David goes to the store”. OneTeam prints it literally.

2. The Jabber server we are using, and I’d bet most others, has an option to send N of the last messages sent in a MUC to the client each time the client connects. This lets the people who are joining the room read up on what has happened there since they last connected. Right now we have our server set to send 100 past messages, in the past we had it set to 200. Unfortunately, with OneTeam, especially over 3G, it can take a considerable amount of time to display all of these messages. I’d love a feature that would remember he last message seen from the previous connect (perhaps using the XMPP message id or a timestamp) and discard all messages prior to that upon reconnect. Less good, but still helpful for a faster reconnect would be something that would discard all or most of the incoming blast of messages upon reconnect.

3. I realize this is tricky given the iPhone user interface, but user/nick/handle name completion, especially in a MUC where the list of users is known upon connect, would be much welcome.

Thanks again for a great client.

  —dNb

Hello,

Thank you for your suggestions.

Regarding point 2, it would not speed up reconnect even if the client discards the messages, because, all the messages would still have to be downloaded.

Regarding point 1 and 3, we will try to implement this in a future version.

Thanks for your response. One question:

Mickaël Rémond - 17 July 2009 04:07 AM

Regarding point 2, it would not speed up reconnect even if the client discards the messages, because, all the messages would still have to be downloaded.

I thought about that, but it appears (to the user) that the client is doing a considerable amount of work after the messages are received. Just judging by how things scroll, I’d be very curious to know just how much time is taken by the download itself and how much by the display/formatting/scrolling code. It would be interesting to see the times for a normal receipt of 200 messages vs. the same 200 messages with the display processing code just commented out. Would it be worthwhile to try this test?

  —dNb