[ demo ] Automated notifications for plugin updates

86 views
Skip to first unread message

Saq Imtiaz

unread,
Jul 10, 2021, 8:30:15 AM7/10/21
to TiddlyWiki
I've been wanting to make it easier to inform end users of my plugins (well really just Streams) that there are updates available via an opt-in mechanism for those that would like such a feature. I realized that for plugins installed via a plugin library, the core actually already does the work and can provide this information, there are just no affordances for it unless one goes and specifically checks.

It turns out that it is embarrassingly easy to set up visual notifications for updates from a plugin library. Here is a demo of a quick 20 minute hack:


Caveats:
1. The major caveat is that the above demo re-uses core UI for plugin updates which is geared towards working with one plugin library at a time. If one wanted to use the same technique as what I have shown here to work with multiple plugin libraries, a custom UI would be needed that could show available updates across multiple libraries in one place. Or you know.... a centralized plugin library that is automatically built at regular intervals from specified plugin sources.

2. The plugins in question have to have a corresponding plugin library installed. We could definitely make it easier to create plugin libraries. However, personally I would prefer to work towards a centralized community plugin library.

3. With the above technique, every time the wiki starts each plugin library is fetched and loaded in the background. So this uses some bandwidth. For reference, the official core library which has 61 plugins is 243kb, whilst the demo library in the video which has 4 plugins is 5kb. So for most use cases this shouldn't be a problem. Furthermore, updates could be configured to only run once a day or week.

4. There are some shortcomings with the core UI for showing available plugin updates.
plugin-updates.png
i) the installed plugin version and the version of the update available need to be far more prominent and easier to read.

ii) There is no information displayed as to what core-version the updated plugin requires and whether that is compatible with the current version of the TiddlyWiki.

iii) While the core UI will display the "readme" tiddler if one clicks the dropdown arrow to the left of each plugin, this isn't the most relevant for plugin updates. What would be more helpful here is to display a release note specific for the new plugin version. Such a release note could contain a link to a fuller changelog elsewhere online. Currently the only option is to include such a release note in the "readme" tiddler, but this leads to a larger size for the plugin library. This is an issue that involves not just the core UI but also the plugin library creation mechanism.

Cheers,
Saq

Jeremy Ruston

unread,
Jul 10, 2021, 10:08:01 AM7/10/21
to tiddl...@googlegroups.com
Hi Saq,

I think an easy opt-in mechanism to detect plugin updates would be worth adding to the core.

One thing that has changed fairly recently is that GitHub Pages is now CORS enabled, so it would be possible to just use HTTP requests, instead of the whole iframe shenanigans. It would be reasonable to stick with iframes for everything that we do at the moment, so that 3rd party plugin libraries hosted on non-CORS enabled servers would continue to work, with just automatic update notification requiring CORS.

Best wishes

Jeremy




On 10 Jul 2021, at 13:30, Saq Imtiaz <saq.i...@gmail.com> wrote:

I've been wanting to make it easier to inform end users of my plugins (well really just Streams) that there are updates available via an opt-in mechanism for those that would like such a feature. I realized that for plugins installed via a plugin library, the core actually already does the work and can provide this information, there are just no affordances for it unless one goes and specifically checks.


It turns out that it is embarrassingly easy to set up visual notifications for updates from a plugin library. Here is a demo of a quick 20 minute hack:


Caveats:
1. The major caveat is that the above demo re-uses core UI for plugin updates which is geared towards working with one plugin library at a time. If one wanted to use the same technique as what I have shown here to work with multiple plugin libraries, a custom UI would be needed that could show available updates across multiple libraries in one place. Or you know.... a centralized plugin library that is automatically built at regular intervals from specified plugin sources.

2. The plugins in question have to have a corresponding plugin library installed. We could definitely make it easier to create plugin libraries. However, personally I would prefer to work towards a centralized community plugin library.

3. With the above technique, every time the wiki starts each plugin library is fetched and loaded in the background. So this uses some bandwidth. For reference, the official core library which has 61 plugins is 243kb, whilst the demo library in the video which has 4 plugins is 5kb. So for most use cases this shouldn't be a problem. Furthermore, updates could be configured to only run once a day or week.

4. There are some shortcomings with the core UI for showing available plugin updates.
<plugin-updates.png>

i) the installed plugin version and the version of the update available need to be far more prominent and easier to read.

ii) There is no information displayed as to what core-version the updated plugin requires and whether that is compatible with the current version of the TiddlyWiki.

iii) While the core UI will display the "readme" tiddler if one clicks the dropdown arrow to the left of each plugin, this isn't the most relevant for plugin updates. What would be more helpful here is to display a release note specific for the new plugin version. Such a release note could contain a link to a fuller changelog elsewhere online. Currently the only option is to include such a release note in the "readme" tiddler, but this leads to a larger size for the plugin library. This is an issue that involves not just the core UI but also the plugin library creation mechanism.

Cheers,
Saq

--
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/68a1febb-e9c5-4f3d-9d5a-5453bca88a16n%40googlegroups.com.
<plugin-updates.png>

Saq Imtiaz

unread,
Jul 10, 2021, 10:49:00 AM7/10/21
to TiddlyWiki
Hi Jeremy,

Using HTTPS requests was indeed my first instinct. I held back on going that route in this exploration due to two reasons:

i) I realized that the core already had everything in place that was needed - including UI - so this was very low hanging fruit for something only meant to start a conversation. 

ii) We still need to address the issue discussed in #4537, namely that simple GET requests by the core via $tw.utils.httpRequest trigger an OPTIONS request which fails on Github pages and other hosting that has CORS enabled but does not support the OPTIONS method. This would need resolving here as well, and I also ran into this problem recently when trying to fetch the changelog for a plugin on demand via a canonical_uri tiddler.

I am curious though as to whether you are thinking in terms of using HTTPS to simply fetch metadata from plugin libraries, or an alternative means of publishing plugins that exposes the necessary information to check for updates. The plus with going via plugin libraries is that nothing needs to change in how plugins are currently published via libraries for them to get updates support. On the other hand a new way of exposing and publishing plugin version information could cut down on the bandwidth required for checking for updates, and perhaps allow including information on what has changed in the new version of the plugin.

I agree an opt-in plugin updates mechanism is worth considering for the core. I'll open an issue to further discuss requirements and implementation details when I get the chance. Some clarity on the potential benefits you see in going the HTTPS route for this, and whether you're still thinking in terms of interacting with plugin libraries via HTTPS, would be helpful in framing the issue.

Best wishes,
Saq

Jeremy Ruston

unread,
Jul 11, 2021, 5:52:32 AM7/11/21
to tiddl...@googlegroups.com
Hi Saq

i) I realized that the core already had everything in place that was needed - including UI - so this was very low hanging fruit for something only meant to start a conversation. 

Absolutely, it’s pretty amazing that it works as well as it does.

ii) We still need to address the issue discussed in #4537, namely that simple GET requests by the core via $tw.utils.httpRequest trigger an OPTIONS request which fails on Github pages and other hosting that has CORS enabled but does not support the OPTIONS method. This would need resolving here as well, and I also ran into this problem recently when trying to fetch the changelog for a plugin on demand via a canonical_uri tiddler.

I had forgotten about that one, it would be great to fix it for the next version.

I am curious though as to whether you are thinking in terms of using HTTPS to simply fetch metadata from plugin libraries, or an alternative means of publishing plugins that exposes the necessary information to check for updates.

I was thinking of using HTTPS as an optional additional metadata channel to enable update checking, and sticking with the current iframe approach for getting the listing and obtaining plugins. The motivation being that we should continue to support plugin libraries on non-CORS enabled servers.

The plus with going via plugin libraries is that nothing needs to change in how plugins are currently published via libraries for them to get updates support. On the other hand a new way of exposing and publishing plugin version information could cut down on the bandwidth required for checking for updates, and perhaps allow including information on what has changed in the new version of the plugin.

Exactly my thinking.

I agree an opt-in plugin updates mechanism is worth considering for the core. I'll open an issue to further discuss requirements and implementation details when I get the chance. Some clarity on the potential benefits you see in going the HTTPS route for this, and whether you're still thinking in terms of interacting with plugin libraries via HTTPS, would be helpful in framing the issue.

Great, thanks,

Best wishes

Jeremy

Reply all
Reply to author
Forward
0 new messages