User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_4) AppleWebKit/536.11 (KHTML, like Gecko) Chrome/20.0.1132.47 Safari/536.11 Steps to reproduce: As with "Delete" method, It's necessary to use an array as param for modifying multiple sms at once in DB through API.
Should we block on that? What would be the use case? Marking an entire thread as read? I feel like we could make this a nice to have and just eat the perf issues in the rare case someone tries to mark as read a ton of SMS (which shouldn't happen). What would be the approximate performance for let say marking 10/100/1000 SMS as read?
It would be nice if markAsRead could take a SMSFilter as well. We call markMessagesRead only in one situation: when the user opens a thread. In this case, we want to mark read all messages in this thread that are not read already. So what we do now is : - create a filter with the number and "read: false" - getMessages with this filter - append all message ids in an array - call our internal markMessagesRead with this array - in our internal markMessagesRead, we're marking each message read one at a time, waiting for the result of each action before doing the next one That's why being able to use an SmsFilter directly in markMessagesRead would be nice: I believe both more efficient and shorter in code.
Sounds like a nice feature to have :)
Here, all what we need (as "business functions") is : * mark as read all messages in a thread (so with a thread id) Right now, what we do in gaia is : * get all messages that are unread for this number (because current SmsFilter does not accept a thread id, that's bug 854790) * mark as read all these messages, one call for each message (usually there is only a few of them) I think the current gaia code is not so bad, performance wise, so I'd consider this as a nice to have.