Hmmm, honestly I'm not surprised. The backend server is quite spartan and I never considered the "refresh" case when writing it. What are you hitting refreshing for?

P/S: a day after image attachments gets released and you're already making use of it - Nice! 😄

Haha, I know, I saw the GH notice about images and thought, "ooh!"

It's not just refreshes. It's reloads of any sort. Usually I find them
happening when I (a) accidentally close the tab and try to reopen it,
or (b) follow a link on the Markdown file and then go back.

On 12/8/12, suan [email protected] wrote:

P/S: a day after image attachments gets released and you're already making
use of it - Nice! 😄

---

Reply to this email directly or view it on GitHub:
#9 (comment)

So I'm very close to completing the rewrite of the backend, which will remove all Ruby dependencies and be much more performant. I'll look into this after that. However, I don't think refresh/back will work without reworking the fundamentals...

There's a highlevel explanation of how everything works here: instant-markdown/vim-instant-markdown#13 As you can see, it would be hard for refreshes to work because we don't actually serve up a page, instead all content is sent over the websocket.

Consider looking at testacular... they do something similar, but manage to track when browsers detach and reattach to the server. (I haven't looked at it myself...)

I suppose the websocket could inform the server when the user is leaving the page, and the server could reinitiate the websocket upon the next request, or something to that effect... if you'd like to contribute that'd be great! (it's just Javascript 😉)