Worth considering: Ease of installing plugins VS. pressure to include in core

[Mat]

Just a thing I've been reflecting over:

The easier it is to install plugins, either permanently install them or - perhaps even more importantly - to do a temporary use+delete install...

...the less the need and pressure to include functionality in the core / std distro.

The coming "dynamic loading of plugins" is a very welcome step in this direction. I can't tell if this is an implementation of the request to Provide a mechanism to register plugins after boot. Another addition was the implementation of making tag pills work for multi-tiddler DnD imports. A more general idea would be a handle to DnD filtered lists. A further step would be to Extend Download button to offer adding plugins. And eventually we'll hopefully be able to solve the Big One, i.e a library that serves a federated collection of plugins.

Apropos this, if installing and removing plugins were totally painless, would it be possible to excise features from the core / standard distro? Just curious.

<:-)

[Mohammad]

Mat,

I was looking at empty.html from 5.0 to 5.1.21 and I see it gets bigger and bigger! May be we have a 5MB or larger empty.html in near future!

I was thinking why not keep the empty.html as small as possible and create a custom taste (different for different users) by adding plugins!

What I propose here, Jeremy can keep core as light as possible and introduce different Official Plugins to make the desired edition (app)

This encourage also people to use and develop plugins! (of course we need some standard for making plugins)

--Mohammad

[Mohammad]

A modular approach!

* core (minimum essential tools)

* themes

* languages

* plugins

** highlight.js

** katex

** codemirror

url: https://medium.com/5000-things/learning-from-lego-a-step-forward-in-modular-web-design-d8ff953f45a8

On Friday, September 13, 2019 at 10:29:44 PM UTC+4:30, Mat wrote:

[Arlen Beiler]

I did an experiment to find out exactly how much space we could save. I took all the Javascript modules, which get loaded during startup, and dumped the code into a file. The file is 1 MB and when I put it through Webpack, it brings it down to 650 KB. Of course, this isn't practical for empty.html, but it was an interesting experiment anyway, and it did work properly. 

I wonder what other optimizations we could do for the HTML store that would improve the storage size. 

For instance, if I dump the entire store area div into a file (which is 2.0 MB) and gzip it, the output is 0.35 MB. The store area actually accounts for 95 % of the file size, I believe, with boot being only 75 KB. For empty.html it is 2.18 vs 0.37. While this is probably not the best option, gzipping the store and base64 encoding it (which increases the size by 4/3) is a realistic option, at lease for the $:/core tiddler. Since empty.html entirely consists of the $:/core tiddler (I just checked), that would definitely reduce the file size. 

Obviously there is something inefficient about the HTML storage system currently being used, because the plugin.info file in TiddlyServer is 1.7 MB and is virtually identical to the JSON stored in the HTML file if I'm not mistaken. One reason for this is that the double quote, which is 1 byte long and appears everywhere, is expanded to 6 bytes in the HTML file (&quot;). This also applies to angle brackets. The plugin.info file is generated with JSON.stringify(core), but the store file is generated with JSON.stringify(core, null, 2), which uses two space indentation and line breaks. However, like I said, this is only creates a 15% increase in file size, compared to gzipping. 

As an interesting side note, GZipping the plugin.info file gives an output of 0.31 MB, which is almost the same as the HTML representation. 

Just some thoughts. 

Arlen

--
You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywikide...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/06c2d171-0304-4193-9587-bf50371908e9%40googlegroups.com.

[SylvainComte]

Or may be it could become something like this

Just kidding of course, but I have ome questions with this approach

* What are essential functions for the core? Who will decide of this? As all of us have already experienced this, there are almost as many visions of what a minimal wiki should be...

* What if my modules combination has some incompatibility issues? For a "simple" user with no coding skills, who will fix this?

* Are we sure we can't make the existing core thiner before we put it in pieces

The success of TiddlyWiki has always been a good balance between "ready to use"-ness, personalization, and hackability.

Edgy to preserve with this Lego game maybe...

Warm regards

Sylvain

@sycom

[TonyM]

I have said this before and will again.

The concept of the minimal wiki, empty.html is essential, and needed for anyone building their own solution where they need to have a totally fresh start and a minimal base on which to build. 

HOWEVER

I believe this should always be the case, but at the moment that is the key way to obtain tiddlywiki, unless you choose an edition. I do not believe empty should be the first tiddlywiki someone takes home to play with. I think we should have a general edition with more in it and possible even reduce empty further.

The General Edition - which is the first offered for download should include to start with;

• Fluid Story, Fixed side bar
• Page Buttons Visible
• Home
  
• Close all
• More
• A Table Of Contents available, and the default sidebar tab.
• Permalink set to copy to keyboard only
• Local Storage plugin installed but disabled (Such that it can be activated) to retain config and customisation settings on readonly sites
• Edit mode tiddler icons using the traffic light colors.
• Active image and date pickers

With a little deeper research a few more items, including things under sidebar > more that help people learn tiddlywiki, like a list of system tags in tagpills, to easy the use of system tags and reordering the view template tags. There is possible an argument for more information under Control Panel > Info like display the values in the $:/info tiddlers, summary of the wikis savers and save status.

Not withstanding the above the General edition should remain fairly minimal and make some reference to other production editions available including empty.

If we have a general edition we can stop this infernal battle between the issues of minimalism and ease of use or accessibility. There is also an argument for a maximal install which would be tiddlywiki.com plus some key plugins which provides a good learning and experimental platform for new and experienced users to "play" with. Loaded with tiddlywiki.com documentation the user can make there own notes and obtain plenty of test data with which to experiment. My first attempt at this is here which I will update soon.

Regards

Tony

[Mat]

(Interestingly, everyone's replies focus on the side note in my OP, but OK...)

Some notes:

• Take care to not confuse the core with the standard distro.
• I believe Jeremy has expressed that a critical aspect with several separate components is the administrative burden to manage/update them. 
• @Arlen... you do the coolest experiments. 

@Sylvain, you write

* What are essential functions for the core? Who will decide of this?

It's an open source project so anyone can theoretically decide whatever they want for their fork. There is only one owner of the main fork so he obviously decides for that one. 

My main OP point though, is that if plugin management was seamless then this would/could have a positive impact on the decision making process about what should go into core or not. It would simplify the whole question a lot, I think.

 

* What if my modules combination has some incompatibility issues? For a "simple" user with no coding skills, who will fix this?

One could argue we already deal with this issue. I don't see how a smaller core or more plugins would change this aspect - ?

 

<:-)

[Mat]

TonyM wrote:

I do not believe empty should be the first tiddlywiki someone takes home to play with. I think we should have a general edition with more in it and possible even reduce empty further.

IMO the ideal would be to - at the "get your own wiki" stage - offer a plethora of editions in addition to individual plugins. The intersection in a Venn diagram showing the functionality of those editions, is probably close to what standard distro currently offers.

The General Edition - which is the first offered for download should include to start with;

[bullet list] 

Your features list is of course no less opinionated that the current standard distro. Instead of proposing specific features I think it is more constructive to first explore purposes, as in "Who is the user?" and "What is the purpose with the standard distro?". For example, one purpose might be to use the standard distro as a wedge to convinces the user to try out more stuff. Or maybe it should be an all-in-one tool. Or a tool that really is just for, say, taking notes but then full fledged to do so. 

Tying in with my initial OP, it is also worth considering that it is probably easier to remove a plugin than to install one, which speaks for rich distros.

<:-)

[Jed Carty]

I think we could probably make an interface similar to what Bob has where you can select plugins from a list of checkboxes that you can check or uncheck to set which plugins you have. In the single file wiki it would then open the correct libraries and get your plugins. You would still need to reload for JavaScript plugins but I don't know if a way around that is a good idea.

[Sylvain Comte]

Reading all of your contributions I do realise that I'm still too close of (one) user's vision and do not understand the core enough.

Some of my questions might appeared naive or very rethorical. Sorry for that, and thanks for answering.

Some answers makes me wonder also. I do not know how is tiddlywiki really used by others. Kind of logical with a tool made to be sort of "very own wiki". And even if TiddlyWiki has one of the most friendly community for users, with an amazing answer rate on the g.group, I guess we miss a lot of questions or frustrations that will never be asked.

No complain here, just thinking loud.

Cheers,

Sylvain

@sycom

On Sat, Sep 14, 2019 at 11:28 AM Jed Carty <inmy...@gmail.com> wrote:

I think we could probably make an interface similar to what Bob has where you can select plugins from a list of checkboxes that you can check or uncheck to set which plugins you have. In the single file wiki it would then open the correct libraries and get your plugins. You would still need to reload for JavaScript plugins but I don't know if a way around that is a good idea.

--
You received this message because you are subscribed to a topic in the Google Groups "TiddlyWikiDev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/tiddlywikidev/7nTAuwRG7h4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to tiddlywikide...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/7ddefe7d-d90b-4002-b7e1-e191c3348c5a%40googlegroups.com.

[@TiddlyTweeter]

Jed Carty wrote:

I think we could probably make an interface similar to what Bob has where you can select plugins from a list of checkboxes that you can check or uncheck to set which plugins you have.

For beginners I'd say that a checkbox system is the way to go.

TT

[Mat]

Jed Carty wrote:

I think we could probably make an interface similar to what Bob has where you can select plugins from a list of checkboxes that you can check or uncheck to set which plugins you have. In the single file wiki it would then open the correct libraries and get your plugins.

 

I like this idea very much.

<:-)

 

[TonyM]

I am all for role your own wikis checkbox driven etc but I believe for new users we need more than empty and we need empty or a minimal version as a base.

Including contents for example helps new users understand and organise even simple info from the start.

However my main point is if we bifuricated, split the primary distributions across these lines we would spend less time concerned with what is standard, core or not core and more placing appropriate content in the appropriate edition. This includes the facility to selectively install and remove plugins. Or build your own edition tools.

I think such an approach would also encourage people to investigate or offer functionally alternative editions not just specific editions as at present.

Current editions are bespoak solutions, I believe we need a small subset of official editions designed by the community to meet community needs and support adoption and rapid development needs. These would be quite simple to manage as forks of the minimal version with a well structured github environment.

Just my view of course and towards a consensus.

Tony

[TonyM]

Post script.

A check box system could be backed up with curated sets of plugins to support various applications or uses. Members could submit new curations as a list of plugins and macros from a consolidated library. Rather than seperate editions. The resulting wiki can record which curations were used to create it. So others can read this for guidance in building similar solutions.

The trick is to build a system that improves with contributions over time.

Regards
Tony