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 > <https://github.com/Jermolene/TiddlyWiki5/issues/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 > > Best wishes, > Saq > > On Saturday, July 10, 2021 at 4:08:01 PM UTC+2 Jeremy Ruston wrote: > 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 > > > > -- > Jeremy Ruston > [email protected] <applewebdata://79D621E2-F5BE-46CB-A423-C078FD401C65> > https://jermolene.com <https://jermolene.com/> > >> On 10 Jul 2021, at 13:30, Saq Imtiaz <[email protected] >> <applewebdata://79D621E2-F5BE-46CB-A423-C078FD401C65>> 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: >> >> https://drive.google.com/file/d/1vIj4BsA5OAhS6eFcKXn0LfJii88E3b6h/view?usp=sharing >> >> <https://drive.google.com/file/d/1vIj4BsA5OAhS6eFcKXn0LfJii88E3b6h/view?usp=sharing> >> >> 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 [email protected] >> <applewebdata://79D621E2-F5BE-46CB-A423-C078FD401C65>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/tiddlywiki/68a1febb-e9c5-4f3d-9d5a-5453bca88a16n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/tiddlywiki/68a1febb-e9c5-4f3d-9d5a-5453bca88a16n%40googlegroups.com?utm_medium=email&utm_source=footer>. >> <plugin-updates.png> > > > -- > 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 [email protected] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/tiddlywiki/d2afd48f-2791-42b0-adaf-c6c495979dfbn%40googlegroups.com > > <https://groups.google.com/d/msgid/tiddlywiki/d2afd48f-2791-42b0-adaf-c6c495979dfbn%40googlegroups.com?utm_medium=email&utm_source=footer>. -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/61ED4602-A17D-4C49-A82C-E2F46544786C%40gmail.com.
