| idec.talks | HOME |
| vit01>> Всё просто, поле по-хорошему increment only. А ещё клиентская часть обычно подстраховывается и скачивает индекс с запасом. mirage> Тогда это уже не количество сообщений будет, а что-то другое. Надо поправить в документации, чтобы не заводить путаницу. Но в первом приближении это обычно и есть количество сообщений. Можно timestamp новейшего сообщения в эхе подставлять, наши клиенты этот вариант съедят даже без переписывания кода. mirage> Ну я сейчас запустил iitxt и он неслолько минут запросы слал по несколько сообщений, а мог бы и быстрее отработать. Дефолт для клиентов - скачивать по 20 сообщений за раз (можно увеличить в настройках), а индекс получать пачками. iitxt медленный, потому что он хитро парсит сообщения и что-то пересчитывает, это к автору клиента вопрос. mirage> Эха содержит список id сообщений. Если новые id добавляются только в конец, mirage> то фетчер может хранить id последнего полученного сообщения и запрашивать от него. mirage> Только возникнет проблема если это сообщение будет удалено. Проблема не только в удалении, но и в том, что сообщения могут не сохранять порядок в индексе базы. То есть они могут быть перепутаны хронологически. +++ Отправлено через IDEC Mobile +++ GNU/Linux, Android, physics, MLP:FIM |