Wiki articles with images do not always load...

[cliveb]

In NYC area on certain home routers wiki articles with picture assets do not load (no matter how long one waits). In NYCPL (https://www.nypl.org) the same articles load after an observable time delay. As I understand it, tries fed wiki instances are hosted at Digital Ocean in Singapore to tease out odd latency issues. Is there any debugging I can do in Chrome dev tools to track down the root cause?

[WardCunningham]

I assume you are talking about the Image plugin and not the Assets plugin. I'll also assume that you are talking about your site, clive.tries...

By hosting a site in Singapore I see higher latency but not lower throughput. This matters for fast small changes, not large pages.

Here is a list of your pages over a megabyte in length.

-rw-r--r-- 1 root root 1010K Jan  3 11:07 wiki-hoa-notes-13
-rw-r--r-- 1 root root  1.2M Feb  8 01:45 deconstructing-bitcoin-whitepaper
-rw-r--r-- 1 root root  1.3M Sep 11 17:52 talk-at-code-camp
-rw-r--r-- 1 root root  1.3M Dec 25 11:43 measuring-value
-rw-r--r-- 1 root root  1.3M Sep 18 22:41 equifax-makes-case-for-wiki
-rw-r--r-- 1 root root  1.4M Aug 28 00:00 ocap
-rw-r--r-- 1 root root  1.4M Jan 25 02:27 wiki-hoa-notes-124
-rw-r--r-- 1 root root  1.5M Feb  7 23:25 wiki-hoa-notes-27
-rw-r--r-- 1 root root  1.8M Feb 14 15:23 neon-orange-book
-rw-r--r-- 1 root root  1.9M Dec 23 03:13 wiki-hoa-notes-122017
-rw-r--r-- 1 root root  1.9M Feb 14 14:23 wiki-hoa-notes-214
-rw-r--r-- 1 root root  1.9M Nov  4 02:32 computer-security-and-crypto-currencies-meme
-rw-r--r-- 1 root root  2.0M Nov 15 12:32 subdividing-the-federation
-rw-r--r-- 1 root root  2.3M Dec  7 13:53 miller-dr-sesing
-rw-r--r-- 1 root root  2.7M Nov 19 13:39 cryptographically-tokenized-assets
-rw-r--r-- 1 root root  2.7M Jan 31 14:31 wiki-hoa-notes-131
-rw-r--r-- 1 root root  2.8M Jan  4 13:35 secure-cooperation-picture-book
-rw-r--r-- 1 root root  2.9M Dec 29 16:21 capabilities-based-dom
-rw-r--r-- 1 root root  3.4M Feb 14 22:10 documents-with-superpowers
-rw-r--r-- 1 root root  4.0M Jan 31 16:19 the-square-and-the-tower---nail-ferguson
-rw-r--r-- 1 root root  5.7M Nov 21 17:19 scaling-bitcoin-conf-at-stanford-cyber
-rw-r--r-- 1 root root  5.9M Dec  2 03:18 unforgeable-distributed-capabilities
-rw-r--r-- 1 root root  6.4M Jan 10 23:34 lets-craft-some-real-attacks
-rw-r--r-- 1 root root  6.9M Nov 21 19:40 ethereum-in-25-minutes

I think if you avoid these pages you will have more success. Let me know if you do then we can talk about how to shrink these pages and avoid them in the future.

[WardCunningham]

Note that as pages are incrementally enlarged they will eventually exceed 5mb which is the payload size limit for operations like "fork". We should probably refuses any edit that grows a page beyond the size that can be forked.

[WardCunningham]

misplaced comment

[cliveb]

Looks like last comment intended for integration of draw.io with fed wiki discussion fedwiki/wiki#108

[cliveb]

Look forward to discussing how to shrink pages. To foster wiki forking I could imagine pixel sized traffic light for didactic UX. Green (go) < 1MB. Amber > 1 MB (caution). Red >5MB (stop). Alas in NYC till March.

[paul90]

In NYC area on certain home routers wiki articles with picture assets do not load

It might be worth investigating if the router is stripping out the base64 encoded image.

[WardCunningham]

Paul might be on to something though I can't imagine where in the stack that might be happening. The Network tab of the Chrome Inspector would be a good place to start an investigation. If screen sharing is working for you then maybe we can video chat and debug this together.

If you have one particular page you need, I can hop on the server and start hacking at that page with a text editor.

We have had many discussions of longer-term fixes but no single fix solves all problems. I consider large images to be the easiest of the "demanding media" and have imagined having all media work well.

http://ward.asia.wiki.org/demanding-media.html

I steer clear of page size problems by habits that have accumulated over the years. I hesitate to suggest these to others because they make wiki seem fragile in a way I wish it weren't. I wrote a page about my workflow this morning.

http://ward.asia.wiki.org/how-i-post-images.html

I am sorry you are having these difficulties. I hope NYC is treating you well otherwise.

[opn]

The whole base64 encoded image thing has turned out to cause a lot of problems for users. It is probably the number 1 reason for lost data in wiki (which is otherwise rare), and of un-for kahle and bloated pages. The description of how to add an image + use a scratch page is one of the more complex things to explain, and yet has little point. Neighbours and foreign servers need understanding, adding an image to a page should be transparent. It would be better (moving forwards) to take this functionality out of the default factory behaviour and replace it with the new asset folder upload and embed behaviour.

…

On Sun, 25 Feb 2018 at 15:38, Ward Cunningham ***@***.***> wrote: Paul might be on to something though I can't imagine where in the stack that might be happening. The Network tab of the Chrome Inspector would be a good place to start an investigation. If screen sharing is working for you then maybe we can video chat and debug this together. If you have one particular page you need, I can hop on the server and start hacking at that page with a text editor. We have had many discussions of longer-term fixes but no single fix solves all problems. I consider large images to be the easiest of the "demanding media" and have imagined having all media work well. http://ward.asia.wiki.org/demanding-media.html I steer clear of page size problems by habits that have accumulated over the years. I hesitate to suggest these to others because they make wiki seem fragile in a way I wish it weren't. I wrote a page about my workflow this morning. http://ward.asia.wiki.org/how-i-post-images.html I am sorry you are having these difficulties. I hope NYC is treating you well otherwise. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#216 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAE71iCPyHJHm_8OZXXAtejQ0wBxWHffks5tYX6DgaJpZM4SR_Mc> .

[WardCunningham]

Server operators are free to provide whatever services they feel useful to their communities.