Arlen Good igea for Gzipping $:/core

[Mohammad]

Aren has given a great proposal at

https://github.com/Jermolene/TiddlyWiki5/issues/4262#issue-493686392

to gzip the $:/core and minimize the size of core!

I support his idea! If you agree discuss this or vote on GitHub

--Mohammad

[TonyM]

Mohammad

Is this the standard trade off between file size and cpu to unpack?. I would imagine slow links and large wikis on big clients would benifit, but would small wikis on slow links be at an advantage or disadvantage? what about large wikis on slow devices?

It may be hard to test the impact on diverse circumstances, devices etc... Unless a simple conclusion can be drawn perhaps this needs to be an option with guidance as to when it is used or not, perhaps even a default like over 5mb zip it.

Just some thoughts
Regards
Tony

[Mohammad]

Hi Tony!

I think these questions are better to answered by Arlen!

By the way, I am supporting smaller empty.html (or better a small $:/core). I also very interested in modular design! Lets people decide what they want alongside the $:/core!

I think maintenance and development workflow is simpler!

Official plugins can be in access to be simply added!

--Mohammad

[TonyM]

Mohammad

I too support a smaller empty and core which is the current standard practice. However I do not want an overly minimalistic edition being users first take home copy of tiddlywiki. Empty plus a few items like the contents tab and active home and more page buttons would be a start, also on modern browsers the wider story view.

Regards
Tony

[Mohammad]

Hi Tony!

That's quite true and your idea is great!

Recommending to download empty.html for newbies is not a good practice at all!

--Mohammad

[Arlen Beiler]

This idea has nothing to do with empty.html itself, it really applies to all single-file wikis. All wikis could benefit from this because the core tiddler is exactly the same in all wikis for each version, no matter which other plugins are added. The core is just another plugin, that's all. 

Unzipping should be very simple in terms of CPU usage, and it should be linear, or better, because it is just expanding back to the original file content. The zipping is where the time comes in, but that isn't much more. TiddlyWiki 5.1.20 takes 70 ms, which is shorter than the minimum resolution of the human brain (~100 ms), so it would be instantaneous for only one or two plugins, but we could also handle all gzipped plugins in one operation instead of one per plugin, which would probably safe some extra space. 

We could also add a config tiddler to the wiki which would allow the user to gzip all installed plugins to save even more space regardless of whether the plugin has the compress:yes field set, since nothing about the gzip process would in any way affect the plugins. 

We should also add a "gunzip" flag (like safemode flag), which would decompress it in place and then immediately re-download the file so it could be edited by hand in an emergency. The file would then be loaded just like normal and then next time it would save with the contents gzipped again. This would be sort of like a safemode flag that would allow someone to edit the compressed plugins by hand if necessary. 

On Sun, Sep 15, 2019 at 9:09 AM Mohammad <mohammad...@gmail.com> wrote:

Hi Tony!

That's quite true and your idea is great!

Recommending to downloading empty.html for newbies is not a good practice at all!

--Mohammad

On Sunday, September 15, 2019 at 5:27:13 PM UTC+4:30, TonyM wrote:

Mohammad

I too support a smaller empty and core which is the current standard practice. However I do not want an overly minimalistic edition being users first take home copy of tiddlywiki. Empty plus a few items like the contents tab and active home and more page buttons would be a start, also on modern browsers the wider story view.

Regards
Tony

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/2a87c261-4de7-4700-a057-f9b4aeb69753%40googlegroups.com.

[TonyM]

Arlen

I would trust your expertise on this. I suppose we need a proof of concept.

Also could I ask that consideration be given to surfacing this within tiddlywiki to users as well. If we could store, compress and decompress and import export files and tiddlers so compressed in tiddlywiki UI it would be fantastic. Imagine a 50mb dataset in a 3mb tiddler.

Regards

Tony

To unsubscribe from this group and stop receiving emails from it, send an email to tiddl...@googlegroups.com.

[Lost Admin]

I had to read through the comments on github a couple of times to understand the proposal.

I'm against it being a part of the default TiddlyWiki (empty.html) because it won't benefit serving TiddlyWiki from a properly configured web server (which should gzip the file before transmitting it). But, I do see your point about it saving (a surprising amount of space) for other methods of deliver (like the email use-case described in the github thread).

I do think it is an interesting idea.

[Arlen Beiler]

I don't think Gzip would have a hangup with it, in fact, I'm pretty sure it would save on compression time. But I don't know that for sure. A lot of  websites don't use compression, however, so I think it would still be a big bonus. 

--

You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.

To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/3e8f6d05-19a3-49cd-9502-e77db31abdb1%40googlegroups.com.

[Matt DeMoss]

I already see 

content-encoding:

gzip

on the initial response from my setup (2.6MB and 636KB transferred). It could be the nginx reverse proxy doing that, but gzip_proxied defaults to off so I think that's coming from tiddlywiki's listener. I don't see it on subsequent responses.

There's probably more improvement to be had from adding headers for controlling cache behavior. (ETag)

I found a project providing an nginx module for etags on dynamic content, but I haven't tried it yet.

On Sunday, September 15, 2019 at 6:35:12 AM UTC-4, Mohammad wrote:

[Arlen Beiler]

The NodeJS server version does indeed serve the index gzipped. My focus is more on single-file wikis, however.

--

You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/b20f9179-49de-40aa-bbf5-0190871cfe4e%40googlegroups.com.