I was doing a poc and came across rest plugin API to retrieve chat history of the room.
But the chat history is non-paginated. Is there any paginated api for that? If not what is the solution ? Please suggest…
Hi!
The GET /chatrooms/{roomName}/chathistory endpoint in the REST API plugin does not support pagination. It is also limited to the chat history ‘old style’, which typically is limited to the last few messages in a chat room (although it can be configured to retain more history).
What you probably want is a REST API that can query ‘all’ history. A message archive that contains that history is implemented by the Monitoring plugin (the feature is referred to as ‘Message Archive Management’).
Although that plugin has a limited private REST API (for public rooms), that’s not really designed for external use. I doubt that it’s paginated (other than that it returns data per day, perhaps).
It is certainly possible to enhance the functionality of this implementation, but that does require some work. If it comes to that (I appreciate that you’re still in a PoC phase), there are a couple of options:
- You can create pull requests with your changes against the source code at GitHub - igniterealtime/openfire-monitoring-plugin: Adds support for chat archiving and server statistics to Openfire
- You can engage with one of our commercial Service Providers and commission this work.
I hope this helps!
Really appreciate the clarity you provided. We’ll be exploring the suggestions.
@guus Hey I would appreciate if you can give me some info on the number of rooms we can create and any limitations on that. Our requirements needs us to make DMs as rooms itself. So I was looking How much rooms we can hold?
This is not going to be the answer that you’re looking for, but: it depends.
The limitations are very specific to use case scenarios. I’ve seen systems with a six-digit number of rooms work, but I’ve also seen systems with a fraction of that crash and burn.
There are so many factors that come into play that it’s impossible to predict things:
- the version of Openfire
- the availability of a cluster (and if clustered, its composition)
- the number of conference services
- the number of rooms per conference service
- the number of occupants per room
- the overall number of occupants
- the percentage of rooms that concurrently see ‘activity’
And that doesn’t even take into account the definition of ‘activity’, which, in my experience, is wildly different between implementations. Only some aspects that are relevant:
- the amount of messages that are shared
- the amount of room leave/joins
- the amount of (other) presence updates in a room
- the amount of historic messages to keep
This is not an exhaustive list.
Finally, the make/model of client software also can make a huge difference. Some clients (or libraries, or self-built solutions) do unexpected stuff that on the surface is benign, but can add up immensely in a busy server.
As you will understand, given all of these factors, it is next to impossible to say anything with any kind of confidence.
It is relatively easy to use Openfire as a development platform, to create a complex system that offers rich functionality to a limited set of users. I’ve seen all to often that such systems grind to a halt when the user numbers increase.
Assuming that you will be developing your own IM solution, the better approach is to, at design and implementation time, be very thoughtful on how certain choices will affect performance of Openfire (and have repetitive performance tests in place).
Not to toot our own horn, but it really does pay to have an experienced developer or consultant at hand, that can help you vet your design.