Copyright prohibits me from posting it here, but I ask anyone who cares, look at

line 517 of /usr/share/rtcom-messaging-ui/html/MessagingWidgetsChatConversation.js

and

line 642 of /usr/share/rtcom-messaging-ui/html/MessagingWidgetsSMSConversation.js,

and tell me if the comment and the following code doesn't concern you. If it doesn't, it should. It also might explain a few things. And just in case, my humble apologies if it doesn't mean what I think it means.

In space, no one can hear you scream.

@daperl: Why would they even want to wait one second before requesting?

Sounds very stupid IMO.

Wonder what would happen if you change it to maybe 100?

If I read the files copyright correctly, without Nokia's permission we can't disclose any information about the file's contents. I'm not sure I was even within my rights, yet the conversation thread posts changes to these files. So, I don't know, but my opinion is that it warrants discussion.

daperl: Interesting.

I assume that you are talking about the artificially introduced 1s delay to allow rendering of the first screen?

Did you try changing the delay? Did it make any difference? Do you think it really takes that long to render a screen of information?

I just did. I put it to 1/10th the value. The behavior seems different but I'm not sure it's better. And I changed it back and forth a few times.

Well, maybe in a Javascript for loop it does, but not anywhere else. I didn't look too closely, but it seems they have a moving window of 100 items with maybe 15 viewable at any one time. So maybe to keep the memory footprint down their playing some prefetching games. But without multi-threading or some form of asynchronous messaging, jerkiness can be expected with this kind of approach. This is a guess.

Just a warning, I noticed that when making changes to the css file, I had to open the conversation window and then close it, then open it again to see the changes I had made. So you may not be opening the window enough to actually trigger the changes.

EDIT: You're right, though, the change seems to be very subtle...

It might be worse than that. I did a diff on two ps's and noticed no change. rtcomm-messaging-ui is always running, but it should be asking for new .js .css .html files everytime.

The only way to be sure is:

kill -9 <rtcomm-messaging-ui pid>

EDIT:

No change in behavior.

No, the only way to be sure is to kill -9 <rtcomm-messaging-ui pid> from space.

FWIW, it's not rtcomm-messaging-ui that is rendering the webpage. That job belongs to browserd (grep for rtcomm - you should see a browserd process with "rtcomm" in its cmdline). You can also abuse browserd for use in your own program; build the stuff found here: https://garage.maemo.org/plugins/scm.../?root=browser and look through the header files. I have a shitty desktop widget that is doing this and it works, somewhat...

Ah, so this browser-neteal stuff is Maemo's gecko equivalent of WRT?