esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Markus Kohler <>
Subject Re: Incremental updates?
Date Tue, 01 Dec 2009 08:09:02 GMT
Hi all,

I thought that if we can send all messages (the last n I guess) we should
also be able to send only the last k  new messages in one batch.
Or is there no easy way on the server to find out which messages have not
yet seen by the client?


"The best way to predict the future is to invent it" -- Alan Kay

On Tue, Dec 1, 2009 at 8:34 AM, Vassil Dichev <> wrote:

> Sure we can just send the latest message, but we have to think this
> through. The corner cases I'm thinking about:
> * if two messages arrive almost simultaneously, it's possible that
> they come in mixed order. This might be fine if we reorder any
> received message by date/id.
> * if someone replies to an old message, a link to the conversation
> would have to appear next to the message. This would be more difficult
> to pull off.
> * the javascript code for rendering the whole list of messages
> (display_messages.js) is currently used for non-comet stuff as well.
> This lets us have a common layout for timelines everywhere in ESME,
> regardless of whether these messages come in real-time or not.
> So this could work, but might have tricky parts to implement.
> On Sat, Nov 28, 2009 at 10:12 AM, Markus Kohler <>
> wrote:
> > Hi all,
> > As far as I can see by looking into the HTTP responses with Firebug, ESME
> > always sends the whole list of messages back to the browser. Uncompressed
> > this was in my case about 43 Kbyte( haven't checked how much it is
> > compressed), which is significant for a single message update.
> >
> > I wonder whether there would be a way in Lift to incrementally update the
> > page e.g. sending only the new messages, insert them into the DOM and
> maybe
> > delete the last messages from the DOM to avoid an unlimited increase of
> the
> > browsers memory usage.
> >
> > Where could I look in the code to understand, how it is currently done?

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message