[TW5] Webworkers and xmlhttprequests

[Jed Carty]

While working on twederation I have been making widgets that will let you incorporate google sheets into tiddlywiki using xmlhttprequests to store and retrieve data.
What the widget does now is spawn a web worker in the background to make the request and parameters are passed to the worker via postMessage, then when the worker gets a response it sends the retrieved data to a listener via postMessage and the widget does whatever manipulation you want with it. Currently in my demo it just prints the output in the console, but it is a json object in the code so it is available.

For now a new worker is spawned whenever a request is made and after sending the response back to the calling widget the worker terminates itself.
I am not sure if this is the best way to do this. Would it be better to create one persistent worker that all widgets that send messages share or is it better for each widget to create a new self-terminating worker each time they make an xmlhttprequest?

The current demo is here http://ooktech.com/jed/ExampleWikis/TWederation/WebWorkerTest/, it doesn't do much past a proof of concept yet. Currently the interesting code is in the tiddlers
$:/plugins/inmysocks/TWederation/action-requestdata.js and $:/plugins/inmysocks/TWederation/action-submitform.js

I believe this is how the plugin library interactions should be handled since it works without stopping the main wiki waiting on a response, but we need to add some notification that the working being active. A notification shouldn't be hard to make, that is more of a note for future jed.

[Jed Carty]

I looked at this a bit more and I think that it may have a broader application than just inter-wiki communication. I am going to have the widget that creates workers and then worker definitions in other places, then you can use the same widget to make different types of workers and get something like threaded behaviour in tiddlywiki. The first example I can think of where this would be useful would be a simple timer. You can make a timer now, but this would be simpler and prevent any negative effects on UX from the timer hogging the main thread. It could also be used for calendar things to spawn notices when certain conditions are met.

I am going to look at it some more, but I think that we could put extensible support into the core for workers and allow new worker types to be defined in other plugins or tiddlers. This could make triggering things on change events easier too but I am not sure how much we want to go with that behaviour.

[Jeremy Ruston]

Hi Jed

The trouble for me with adopting webworkers is the fact that they only work when served from an HTTPS URI. That rules out using them with a file:// based TiddlyWiki, or with TiddlySpot.

As an aside, over and over again in the last 10 years, I’ve had moments of excitement as browser manufacturers have announced more features to support offline working. However, each time, we find that they are entirely focussed on bringing those enhancements to traditional online services (like those operated by Google), and don’t actually help our central use case.

Best wishes

Jeremy

On 25 Apr 2016, at 08:06, Jed Carty <inmy...@gmail.com> wrote:

I looked at this a bit more and I think that it may have a broader application than just inter-wiki communication. I am going to have the widget that creates workers and then worker definitions in other places, then you can use the same widget to make different types of workers and get something like threaded behaviour in tiddlywiki. The first example I can think of where this would be useful would be a simple timer. You can make a timer now, but this would be simpler and prevent any negative effects on UX from the timer hogging the main thread. It could also be used for calendar things to spawn notices when certain conditions are met.

I am going to look at it some more, but I think that we could put extensible support into the core for workers and allow new worker types to be defined in other plugins or tiddlers. This could make triggering things on change events easier too but I am not sure how much we want to go with that behaviour.

--
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 post to this group, send email to tiddly...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywikidev.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/bf964e75-9c64-488d-b9d8-b22de374010d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jed Carty]

That is very annoying. I hadn't figured out where the bad URI errors I got while testing, I thought I was copying urls incorrectly or something. With that restriction this becomes much less useful in general. I think they can still be used for some multi-threading but I don't know how generally useful that is going to be since we can already make daemon processes as startup modules.
I will play with it some more and see if I come up with any good uses.

[Jeremy Ruston]

Hi Jed

That is very annoying. I hadn't figured out where the bad URI errors I got while testing, I thought I was copying urls incorrectly or something. With that restriction this becomes much less useful in general. I think they can still be used for some multi-threading but I don't know how generally useful that is going to be since we can already make daemon processes as startup modules.
I will play with it some more and see if I come up with any good uses.

On the bright side, HTTPS is easier to implement than ever. Cloud services like CloudFlare can be used to retrofit SSL onto existing services like tiddlyspot.com. Then there’s things like "Let’s Encrypt" that aim to make setting up and running an SSL server cheaper and easier than ever.

These issues also lead me to believe that TW should support HTTPS in the core so that it’s easy to run a local HTTPS server for personal use and testing.

Best wishes

Jeremy

--
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 post to this group, send email to tiddly...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywikidev.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/df31e541-f465-4d8a-bb94-a6c09e2b9e14%40googlegroups.com.

[Jed Carty]

From what I can see you can use in-line js to create a worker from a blob if you are not on an https domain, but if you are on an https domain than you can only load workers from an https domain and I have seen online that making a blob into a data uri is considered to be from a non-https domain. If that is the case than we wouldn't be able to host a wiki on an https domain and define the workers inside the wiki itself. I don't have an easy way to test that at the moment, but if that is true than workers may turn out to cause trouble even for simple threaded behaviour.

[Jeremy Ruston]

Hi Jed

One brightspot is that Github Pages does support HTTPS, but not at the same time as a custom domain.

So your GitHub pages can be access equivalently as http://inmysocks.github.io or https://inmysocks.github.io

It’s probably occurred to you before, but there’s no reason we couldn’t make saving to GitHub just as easy as saving to TiddlySpot. The GitHub API is very clean and easy to use.

Best wishes

JEremy.

On 26 Apr 2016, at 09:00, Jed Carty <inmy...@gmail.com> wrote:

From what I can see you can use in-line js to create a worker from a blob if you are not on an https domain, but if you are on an https domain than you can only load workers from an https domain and I have seen online that making a blob into a data uri is considered to be from a non-https domain. If that is the case than we wouldn't be able to host a wiki on an https domain and define the workers inside the wiki itself. I don't have an easy way to test that at the moment, but if that is true than workers may turn out to cause trouble even for simple threaded behaviour.

--
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 post to this group, send email to tiddly...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywikidev.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/5d61beda-0fd3-46b1-8b62-eda24f189cca%40googlegroups.com.