Re: How to handle persistent chat rooms / conversations

On Sun, 2017-06-25 at 20:49 +1200, Eion Robb wrote:
> Good point. The trick there is that those IDs are assigned by
> libpurple, not by the prpl, there's no API for the prpl to attach an
> arbitary (and persistent) ID to a received message

That's hardly a new thing; we have to maintain a table to convert. We
have the same problem for various other things like buddies, where we
can't use a unique ID from the prpl and have to have other methods to
work it out.

It'll be good to be able to handle message receipts... but I'm not sure
this really addresses the 'persistence' problem especially across
multiple invocations of the application.

I was pondering a new message flag PURPLE_MESSAGE_HISTORICAL (or
_NO_NOTIFY) which would indicate that an incoming message isn't
actually new and shouldn't trigger a notification.

So when I first establish the account, I'd fetch all the historical
messages in each conversation and call serv_got_im() with this new
flag. The messages would get put into any log that the application is
keeping, but *wouldn't* cause a window to pop up immediately. And
if/when I later communicate with the same buddy, I can see the
historical conversation just as if it'd really happened using this
client.

I'm still unhappy with the way the Pidgin UI handles those separate
sessions as completely different logs, each time you close and reopen
the window, but that's mostly a UI thing and probably not something I
can address at the prpl level.

Eion, you mentioned something about logs growing too much if we fetch
historical messages... but that isn't a new problem; it can happen even
now if there's a lot of traffic. They need to be rotated/expired
anyway. So I'm not too worried about that.

_______________________________________________
Devel mailing list
[email protected]
https://pidgin.im/cgi-bin/mailman/listinfo/devel