Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling

Y.A.N.F: Private Message XML Ticker

by demerphq (Chancellor)
on Jun 26, 2004 at 20:59 UTC ( [id://369872]=monkdiscuss: print w/replies, xml ) Need Help??

Hello Folks, Yet Another New Feature announcement....

I've made some changes and "improvements" to the Private Message XML Ticker that will hopefully allow folks to make better CB clients, and also which should in the long term allow us to reduce the server load that feeding all those CB clients causes.

The changes for now should make no difference to anyone using proper XML parsing techniques. However by August 1, 2004 we will put in place a restriction on the number of records that will be returned by the ticker. At this point any client expecting to get all of their private messages from a single fetch will no longer work.

The main changes are to the interface. We now support a number of extra arguments. They are as follows:

Currently this may be 'clean' or 'default', anything else including omitting the paramater will be treated as though it were 'default'. In 'clean' mode no newlines are added to the inside of data containing elements. The 'default' will continue to add a newline to the messages to keep the hysterical porpoises happy.
This parameter, which defaults to 0, is the message_id that all returned messages will be higher than. Thus it is NOT inclusive. This is to allow clients to easily only fetch new messages, and not the whole lot on every fetch. Clients can simply set the since_id to be the same value as the highest message_id they have seen from the ticker before and get only new content.
This value may be 'both' in which case both archived and nonarchived messages will be returned. Otherwise any FALSE value or 'no' or omitting the parameter will result in only nonarchived messages as it was before this rollout. Any other value which perl thinks is TRUE will result in only archived messages being returned.
This determines how many records will be returned with the fetch. It is hard limited depending on what the 'archived' parameter is. If 'archived' is TRUE then this limit is currently 100 records at a time. If 'archived' is false (meaning private messages only) it is currently set to 10_000 records at a time. This is to keep the hysterical porpoises happy, and as is stated above WILL be changed to the same hard limit as when archived messages. This change will occur no earlier than 2004-08-01. This should allow people plenty of time to convert your clients over. (All of you who have to do this should thank theorbtwo for the time given to do so as I'm a hardass when it comes to hysterical porpoises and I would have just enforced the same limit from the get-go. Incentive and all that ;-)

Additional changes have been made to the INFO tag, with several additional status attributes added to make debugging and etc. easier. Please review the ticker itself for details.

Anyway, I hope these changes are useful to you all.

sporty: we expect to see a new KB rollout using this stuff PDQ man, and don't forget the char length restiction... ;-)



    First they ignore you, then they laugh at you, then they fight you, then you win.
    -- Gandhi

• Update:  
castaway kindly pointed out that I had misnamed since_id as from_id. I blame exhaustion, but accept full responsibility for the mistake. Please accept my apologies if this has caused anyone to waste time debugging this "error".

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: monkdiscuss [id://369872]
Approved by BazB
Front-paged by Corion
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others scrutinizing the Monastery: (3)
As of 2024-04-22 23:15 GMT
Find Nodes?
    Voting Booth?

    No recent polls found