I know I’m not alone in being interested in the new Worker class that Geoff introduced in the XDC 2020 keynote. We know that it won’t make the 2020 Release 1 build but I was hoping it would arrive in release 2. I took a look at Xojo’s public roadmap (which is always changing) and I’ve noticed that “multicore” (which I’m taking to be the Worker class) has slipped to number 5 (after AOI 2.0 for iOS and plugins for iOS). Given how much of an undertaking API 2.0 for iOS is likely to be, I don’t imagine we’ll see the Worker class until the end of the year if we’re lucky. Shame.
1 Like
When I say “Xojo Workers” my first thought was “employees” 
1 Like
Not surprising given the number of “not finished” and “not working” items in the current beta prerelease. As has been said many times, they just don’t have enough resources to accomplish any of their goals in a reasonable timeframe.
2 Likes
R1 is pretty much set. Web 2.0 is the only big thing that will be in it. Nothing else will go into R1 unless its critical.
They just have some MAJOR bugs to fix in it
No, that will be R1.1! 
There are at least 2 that there’s no way they want to let them out the door
That they got out to “beta” is bad enough
Don‘t get why they didn‘t release a bug fixes only version in March and push Web 2.0 to R2 …
Maybe they were in a state where they couldn’t do that ?
No idea
While I’m looking forwards to having the full blown “workers” class in Xojo, I actually think that Xojo aligning their IOS targets with API 2.0 is of a greater priority.
Especially if it means that we’ll be able to use Workers on iOS.
1 Like
If those workers remain as isolated as they are they wont be that useful
they have a long way to go to make life really useful
I know, you know, they know. I’ve offered my Sandbox safe shared memory code to help.
I’m not too keen on having to use API 2.0 either, but I guess it will a lot easier than having to port my entire application to Swift.
Oh I dont even mean that
Marshalling data back and forth is an entirely different issue - but certainly crucial
Right now what Geoff showed is basically a console app that ONLY has a run event an doesnt include any other methods / modules from the rest of the app
That really limits what you can do
And it remains to be seen how they’ll make it clear that you cannot pass object references in from one side to the other
I guarantee folks will try & create a new instance and set properties from their objects in the main app then wonder why things wont work
There are a LOT of issues to sort out. Joe and I had discussed a scheme like this but never took any action because we couldn’t figure out how to deal with some of them so it was more just he and I sitting around bullshitting “What if …” than anything
No code. No work was done. Just talk
And I expect that as Xojo works on this they’ll bump into those same things so it remains to be seen how they solve them
1 Like
Buy you geniuses never had me there, I could help increase the bullshit talk by 50%, even if it’s way over my head
1 Like
Whilst it’s disappointing that it’s slipping I have to say that it’s probably a good thing - it might mean they are refactoring it.
As I said on the other forum, the immediate use case that came to my mind was parsing lots of Markdown files with my MarkdownKit (which is a Xojo module). Unfortunately, in the current iteration, the Worker wouldn’t have access to the MarkdownKit module and so wouldn’t work in this situation.
Is there a list anywhere of what these fixes might be? It would be nice if the pre-release notes gave a list of feedback numbers (of bugs reported before the 2020r1 testing cycle began) whose fixes they are including in 2020r1. That way, we could test those too.
Edit: sorry - misread your post and now see it wasn’t referring to prior bugs.