<isd>
I'm tempted to suggest writing our mongo migration script in Go. Reasons: (1) official driver actually supports mongo versions all the way back to 2.6, which is the ancient version we're using; with js we'd have to bundle two different versions of the driver package. (2) We already have Go as a build dependency, due to boringssl's testsuite, so while we'd be adding a new language as far as our own code goes, we wouldn't be adding a new build
<isd>
dependency, so that seems a bit more sane. (4) I am much more confident that the build for such a tool will continue working in the future; with basically anything else I'd worry we'd end up with another binary that's difficult to reproduce due to ecosystem bitrot. (3) I think this will take me at least one order of magnitude less time to write than fussing with the tooling in some other language to get this done.
<isd>
kentonv: do you have strong objections to the above?
<ocdtrekkie>
While I know we'll likely ship this for a long time, do we expect any server will end up using it more than once? i.e. do more modern Mongo upgrades require such hackery?
<isd>
It seems quite possible
<isd>
They definitely have the expectation that upgrading can require manual intervention, so if we're stuck with mongo for the long haul, we probably will need to do this again.
<isd>
My fantasy is still to replace mongo with sqlite.
<isd>
(I don't think this is a serious option in the near to medium term, obviously. But maybe someday if we have the resources)
<ocdtrekkie>
Obviously kentonv is the end all on it, but my first impression is that for a migration tool that massively unsticks our platform, whatever gets it done reliably and affordably time-wise is probably worthwhile. Apart from further future Mongo migration questions, it also seems like "eventually deletable" code, so if we got to a point where it was unpleasant to have Go code in our build it seems like something we could prune in the future.
<isd>
Yeah, that's my feeling.
<isd>
And especially since its use is coupled to an old mongo version that we're stuck shipping a binary blob of, just shipping the binary if we really wanted to rip go out of the build system would also not be horrible
<ocdtrekkie>
Yeah that too.
<xet7>
For WeKan, I'm writing migration tool, but I have not yet decided about what programming language
<kentonv>
isd, this sounds reasonable. Go also has the advantage that we'd end up with a nicely self-contained binary. I suspect once it works we'll never even rebuild it, just continue sticking the same binary in every release forever, like we do with MongoDB itself.
<isd>
Ok cool
<ocdtrekkie>
xet7, I think FerretDB is super interesting because a wire-compatible protocol is absolutely needed for Meteor compatibility, but right now we just need to unstick our present Mongo version.
<kentonv>
if we need a future migration, it'd be a new binary probably
<kentonv>
I suspect Go's mongodb driver will actually drop support for 2.6 at some point -- another reason to just build the binary once and keep that forever.
<isd>
Re: wire protocol, I wonder if we could just monkeypatch the mongo driver api on the js side, and talk to a wrapper binary via capnp... I have to head out though. later.
<xet7>
Go dropping support for various operating systems etc worries me, like also my previous failed attepts to code with Go, ending up in crashes etc. That's why I have been looking to FreePascal and other programming languages.
<xet7>
at
<xet7>
And also thinking, that because some platforms only support Javascript or compiled-to-Javascript (like CloudFlare and Friend), do I need to just try to continue with Javascript, like before
<xet7>
Serverless is also Javascript, although some platforms have options for other programming languages
<xet7>
There was some serverless issues about something not supported yet for cloudflare workers or something
<xet7>
it would be nice to use serverless to code for all serverless cloud platforms, with same kind of APIs
<xet7>
Although I don't know are all those cloudflare-specific, or would there be possibility to use those with serverless
<xet7>
And how to run serverless on Sandstorm
<xet7>
For current WeKan code, I'm trying to separate Javascript code to independent parts, that could be run with CGI or serverless
<xet7>
Because current Meteor WeKan version has growing CPU and RAM usage
<xet7>
running with CGI would be similar like with PHP, all RAM would be freed at end of request
<xet7>
Then there is question, when Miniflare requires newest Node.js, would that Node.js version run on Sandstorm. Is Sandstorm version of Node.js some special fork, or is Node.js version depending on what Node.js version Sandstorm itself uses.
<xet7>
I'm also thinking, would it be possible to compile Node.js for i386 operating systems, like Win7 32bit, or WinXP 32bit, or Linux 32bit.
<xet7>
Other option would be to use Haxe to transpile to Javascript, that Javascript does run on newest Node.js . But transpiled code is somewhat more verbose that written-by-hand code.
<isd>
You should be able to bundle any version of node in a sandstorm app.
<xet7>
Every operating system version is still in production use at the world
<xet7>
and there are big supply chain issues
<ocdtrekkie>
I think there's probably a point where you got to cut it off though. To even get security updates for Windows 7, you have to pay Microsoft an extra subscription fee.
<xet7>
WeKan is used at internal company networks, that are not connected to Internet
<isd>
Also, that looks like it's about browser compatibility, so it shouldn't matter what the backend is running.
<xet7>
Yes, browser compatibility is about using correct HTML/CSS at page, so that webpage is visible
cwebber has joined #sandstorm
kentonv has quit [Ping timeout: 255 seconds]
kentonv has joined #sandstorm
<ocdtrekkie>
Ian, it might make sense for your upgrade tool to be somewhat detachable from the Sandstorm codebase for another reason: I think meteor-spk needs it too.
<ocdtrekkie>
I think xet7's issue with upgrading Wekan was the same issue with the old Mongo, wasn't it?
<isd>
Probably, yeah.
<isd>
Otherwise we're basically stuck not upgrading any meteor apps ever.
<ocdtrekkie>
meteor-spk's readme says it uses Mongo 3.0 now, but I know there was a similar brick wall at upgrading to the new Meteor.
<isd>
... Might also just be a good playground for ways to escape mongo
<kentonv>
ocdtrekkie, I believe meteor-spk automatically bundles a little program that does a mongo migration from 2.6 to 3.0 if needed
<ocdtrekkie>
That sounds familiar. I think Meteor 2.7 drops both 2.6 and 3.0 support though, hence Wekan's present predicament.