kentonv changed the topic of #sandstorm to: Welcome to #sandstorm: home of all things sandstorm.io. Say hi! | Have a question but no one is here? Try asking in the discussion group: https://groups.google.com/group/sandstorm-dev
griff_ has quit [Quit: griff_]
griff_ has joined #sandstorm
_whitelogger has joined #sandstorm
griff_ has quit [Quit: griff_]
_whitelogger has joined #sandstorm
griff_ has joined #sandstorm
griff_ has quit [Ping timeout: 246 seconds]
xet7 has quit [Remote host closed the connection]
Zertrin_ has quit [Quit: 0096 2251 2110 8105]
Zertrin_ has joined #sandstorm
<JacobWeisz[m]> Wow, Ian! I was not expecting this today.
<isd> I'd been planning on working on SandCal, but this caught my attention instead :P
<JacobWeisz[m]> The only thing I worry about is like deprecating httpGet, if our timeline will be based on private apps or apps we can't patch.
<JacobWeisz[m]> Contact Otter for instance will not be updated.
<JacobWeisz[m]> I think Kenton will have to opinionate, but I wonder if a hidden rollback key is a good idea here too. I'd like to do what we can to fix apps ahead of it, but I really want to enable it for everyone sooner rather than later.
<JacobWeisz[m]> rollback key = the database thing you did for httpGet.
<JacobWeisz[m]> And I really don't want to tell someone they have to lock themselves to an old Sandstorm version or something horrible.
<isd> Yeah...
<isd> using a db key in this case would be more annoying though, as this is handled in the C++ code which doesn't have easy access to mongo.
<isd> A config option might be easier in this case.
<JacobWeisz[m]> draw.io would be another hard one to update, though we have community interest in doing it.
<isd> I'm okay with breaking things for this as long as it's not "this app is completely unusable."
<JacobWeisz[m]> Config option is fine too, I think these should be temporary and hopefully never used so whatever is easiest I think should be okay.
<JacobWeisz[m]> Presumably if the breakage is troublesome enough for someone, they can undo the change on their server, and then have x months to update the app before we deprecate the option entirely.
<JacobWeisz[m]> I do think Kenton had talked about maybe having an old API version and a new one rather than breaking old SPKs for big platform changes like these.
<JacobWeisz[m]> If he feels strongly about that, at least we could handle both these major platform changes at one time.
<isd> I mean, that works for things that aren't security holes. But this we really need to hard break at some point.
<isd> I'm okay with adding an option to give folks time to migrate if this breaks anyone, but otherwise I think the sooner we do this the better; it'll just be harder the longer we wait.
<isd> I don't plan on breaking compatibility for non-security reasons ever, if I can avoid it.