Wiki pages can run out of memory and lose precious content due to images

[cliveb]

Asked about before but I keep falling into this trap.

• Taking live notes using wiki.
• Take screen shots to capture context
• Roughly about after adding the 3rd screen shot wiki loses the ability to save the live page to the server.
• When this happens on ChromeOS I try to fork the live page, but the fork controls are out apparently also out of memory

Is there any way to make wiki page memory more robust for normal users?

• Modern phones and laptops now have retina high resolution screens (that induces large images using memory)
• Could a new halo color indicate the page is out of memory (the page will save null before it can be backed up by overnight process).
• Could the page self-fork rather than commit page suicide...
• Could images automatically save a lower safer resolution....
• Just some ideas, because I think wiki needs to be more memory safe (ChromeOS does not have all the fancy of MacOS, Unix or Windows saving a local page copy to cache). Chromebooks are often a default option for schools.

http://clive.tries.fed.wiki/view/wiki-devuser-video-chat-fed-20#

[cliveb]

i.e See your page, add images -> page is killed

[cliveb]

I'm unsure what exactly is going on with wiki (maybe the server is not writing) I tried making a manual copy (unsure if it is saving) http://clive.tries.fed.wiki/view/wiki-devuser-video-chat-fed-20-copy#

Google Chrome OS Your Chromebook is up to date Version 73.0.3683.32 (Official Build) beta (64-bit).

[WardCunningham]

I can't explain the blank page.

I do see your page when I browse from here.

I see one image, but I also see other images when I recall earlier versions from history. All of these images take space. How much, we'll check with wc:

curl -s http://clive.tries.fed.wiki/wiki-devuser-video-chat-fed-20.json | wc -c
 12160001

That's 12 mb which exceeds the server's post limit of 5 mb.

You can make a page too large to fork because edits increment the size of the page up while fork attempts to save the whole page in one operation.

You can save large images as assets and then refer to those in html formatted items. I will write this up somewhere and post a link here.

[cliveb]

Thank you.

Now recalling earlier at my work. We saved images s/m/l/xl (automatically like Flickr does). We only displayed the thumb nail inline with text. Assuming this flow, I guess I'm interested in how the client can learn about the servers memory limits. A configuration setting has to be published in the wiki's api. i.e. there is no silver bullet or function in web based distributed system to pass parameters around (no 'get out of prison free' card).

Ah now I grok pull/226

[WardCunningham]

The 5 mb limit is a parameter that the server operator can change. If our goal was to be more like flickr then saving images would be a higher priority. I suggested this to Nick when he had his first child but he already had some other solution. The problem with most solutions is that they break the promise that you get the whole page when you fork it. We've broken that promise with the Assets plugin which will at least tell you what you don't have.

[nrn]

It would have been a fun project, but ultimately what the grandparents wanted was essentially an Apple photo stream anyway :D

[paul90]

There was an issue with images not getting squeezed. This has been fixed by fedwiki/wiki-client#262 - and include with wiki-client v0.20.2

[cliveb]

Image squeezing sounds just real practical. I feel I already benefit from the fix (http://clive.tries.fed.wiki/view/two-phase-commit-vs-polymerase-function)