ChanServ changed the topic of #sandstorm to: Welcome to #sandstorm: home of all things Sandstorm and Cap'n Proto. Say hi! | Have a question but no one is here? Try asking in the discussion group: https://groups.google.com/group/sandstorm-dev | Channel logs available at https://libera.irclog.whitequark.org/sandstorm
drkokandy has quit [Ping timeout: 260 seconds]
drkokandy has joined #sandstorm
TMM__ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM_ has joined #sandstorm
larjona has quit [Ping timeout: 265 seconds]
<isd> So, tbh I would have been astonished if the meteor devs were open to maintaining support for mongo that old. I think we're probably on our own here.
<ocdtrekkie> I agree, though I think it's worth highlighting that only supporting SSPL databases is a pretty big issue for open source projects like ours.
<ocdtrekkie> Ultimately we may find a workaround that but it'll still be a problem for them.
<TimMc> I'd be curious to hear the context on this.
<TimMc> People are still touchy about SSPL, huh?
<TimMc> oh, misread -- this is the thing where metor dropped support for a bunch of *older* versions of Mongo
<TimMc> Kyle Mitchell has a great post about why SSPL is open source, in contrast to the Commons Clause (which is what people get it confused with): https://writing.kemitchell.com/2019/06/13/SSPL-Not-Commons-Clause.html
<TimMc> Getting off of Mongo is something I'd support for other reasons, though. :-P
<isd> Yeah, SSPL is maybe 3rd or 4th on my list of reasons to get away from mongo
<TimMc> heh
<TimMc> (he also has https://writing.kemitchell.com/2021/01/20/Righteous-Expedient-Wrong.html excoriating OSI for some deceptive statements around the SSPL)
<ocdtrekkie> I will have to read those, heh. I am supportive of SSPL personally but I think it's challenging while the OSI is considered as authoritative to ship SSPL stuff. Too many people literally call it "proprietary" just because the OSI said no.
<isd> Meh, I understand the the push to say "not OSI" doesn't count; SSPL is is more defensible, but usually when some company calls their product "open source" but is on some other license, it's something that's blatantly not -- e.g. cockroachdb has something that is more directly "you can't make a competing product"
<isd> better than a full-on ms style EULA, but I get the worry about watering down the notion.
<kentonv> can we just write a Mongo emulator based on sqlite and migrate to that? How hard could it be? (half-joking)
<isd> I mean, that's almost FerretDB, but it's postgres instead of sqlite.
<isd> Doesn't have oplog yet though, so not ready for us
<kentonv> I think the oplog only matters if you have multiple clients
<isd> Doesn't meteor's subscription stuff depend on that?
<kentonv> (where the "client" is the Meteor app)
<kentonv> I think if you have only one instance of the Meteor app, Meteor doesn't actually need the oplog? Or at least they didn't originally.
<kentonv> I mean, originally Meteor didn't use the oplog at all, just did in-memory stuff, and it was a problem if you had multiple instances. I could totally imagine they've grown dependent on it since then, though.