Re^2: Archived messages through xml ticker (reason)

Database load.

In particular, there were people with hundreds of archived messages fetching the entire list every few seconds in order check if there were any new ones (that is the way all of the external chat clients that support displaying private messages work).

The ticker would first need to have a parameter added that says what the last message you saw was so that it would only show new messages and all common external clients updated to use that parameter.

However, archiving and unarchiving of messages are completely under the control of the user so there is no reason that external clients need to poll for changes to archived messages. So even supporting XML access to archived messages is a low priority.

Rather than wait for archived messages to be available via an XML ticker, you might want to write an external client that you use to archive messages and get the XML before you do so.

- tye

Comment on Re^2: Archived messages through xml ticker (reason)

Replies are listed 'Best First'.
Re^3: Archived messages through xml ticker (reason) by Coruscate (Sexton) on Nov 26, 2003 at 19:42 UTC
Do you believe that requiring a parameter passed to the xml ticker (such as the ";archived=1" I suggested) would be abused in such a way that people would still try fetching the entire list? Requiring that parameter would make so that current external clients wouldn't be grabbing them without knowing (such as framechat) should work well, as long as once the option were introduced it isn't abused. As for users fetching 100+ archived messages, shouldn't there be a limit on the number of archived messages? I seriously doubt anyone here really needs to be capable of holding so many private messages for future reference. Surely if anyone has such a high number, it's because they archive every single messages they receive, which is just not necessary. Or maybe they are someone popular who gets a /msg every 30 seconds here. Either way, should some limit on how many messages may exist in your message inbox be applied? Another solution might be to only return the 10-15 recently archived messages. Where every time you hit the server for archived messages, you're just going to get the same 10-15. That way, to get at the others, you'd have to delete those first 10-15 messages (whether you're storing them in the external client first is naturally up to you or the client software). Then, the next hit to the server would produce the next 10-15 most recent archived. This sounds like a viable solution to me.	[reply]
Re^4: Archived messages through xml ticker (no) by tye (Sage) on Nov 26, 2003 at 20:13 UTC
(such as the ";archived=1" I suggested) would be abused in such a way that people would still try fetching the entire list? Um, I must be missing something. Based on what you've proposed, how would they manage to do anything else? Perhaps what you meant to ask was if I thought people would write clients that fetch the entire list of archived message instead of just the entire list of unarchived messages. "If you build it, they will come." In other words, I have no plans to try that experiment simply hoping that people don't use it. I seriously doubt anyone here really needs to be capable of holding so many private messages for future reference. Surely if anyone has such a high number, it's because they archive every single messages they receive Um, " • Plus 24 more, 1315 archived" and I assure you I delete plenty of messages. Messages sitting in the archive aren't a problem. A worse problem is that people could have tons of unarchived messages and be using a client that fetches the whole list over and over. So far I haven't noticed that happening, but that should be addressed before worrying about archived messages (which is what I mentioned already). No. If we are going to add archived message support to the ticker, it will require a "since" so that we aren't repeatedly returning the same 10-15 messages. There will probably also be a limit imposed such that if you ask for all message (archived or unarchived) since "0", you'll only get the first N and have to make a second request to get the next chunk. - tye	[reply]