DougS This would be a very useful feature for either version of the API. We often have requests to build custom components based on unread messages in topics, often for super users who want to keep track of new comments in topics they are participating (at least that's what we know, the other users might use it as well). Unfortunately it is very (very) bad for performance to fetch entire sets of messages, looping over them just to see if they are already read, fetching another set to get more in case the desired amount is not reached yet etc. etc., caching can help a bit, but still the entire use case is very inefficient to implement. Maybe something for the backlog (on top please =D)?
I did a search in the Li Product Ideas board and found this thread:
It looks like it was archived due to not getting enough kudos to make it onto the product roadmap. I'd like to see this make it onto our roadmap, but unfortunately it is not my call. I'd recommend either lobbying to re-open this idea, or add a new idea for this (and maybe link to the old one) and getting some users to kudo it.
I agree that it's not ideal to have to code something to keep retrieving more messages when not enough unread messages are retrieved, and that seems like it gives us some more weight to implement this.
Yeah its probably taken everyone longer to type the replies here than to implement this.
Given the field already exists in the message collection it would just simply be allowing it to be a constraint in a Liql query.
Unfortunately it's not quite that easy to implement, since what messages are read/unread are different for each user.
DougS is exactly right, the implementation is actually quite ugly and prone to errors and strange behaviour, especially when combined with some sort of caching (component cache, usercache), it can be done, but it's definitely not pretty. If I find time I'll try to resurrect the idea, thanks for the link!
If I already have DougS on the "line" =): I was recently digging trough the docs and community because I though I had read (once upon a time, but couldn't find it...) that the Lithium REST API's internally cache requests (e.g. outside of appcache, usercache, component cache). Is that a) the case and b) for how long and c) if it is the case, can that value be adjusted by support or is it global?
