> > - Tighter sync between mirrors and us.metamath.org > > I don't think that's critical. We update 1/day, and it's not a crisis if > the mirror update is delayed. Also, rsync is *really* fast at determining > "there is nothing to do".
Good point. With a slow, prescribed update cadence, this point is far from critical. I'm thinking a bit more broadly, however. It sounds like the current HTML-generation process is quite slow, but if something like localized incremental updates becomes possible, then it's not hard to imagine "live" updates of the site every time an MR gets merged in. It mostly boils down to an experiential difference---"live" updated page vs "static" site with periodic updates. I'm clearly biased to thinking the former is way cooler. > We really *can't* handle such errors. If the other side is inaccessible, or > can't write an update, there's little we can do about it. SMTP might like to have a word about that :D Transient network errors have to be handled or ignored by *someone*, be that us.metamath.org or the mirrors. > > - Might require updates to Firewall settings > > Not really, and we control our firewall settings anyway. I'm thinking more broadly of the us.metamath.org + mirrors distributed "system". Potential firewalls around each node. > There's a bigger "con": the mirrors would need to allow > someone from the outside (specifically us.metamath.org) to log in > *to* their system & write to it. I don't know if they're willing to do that. > They may not even have the rights necessary to do it. > That's not a technical issue, but it certainly might matter :-). > > Another con: It'd mean that the us.metamath.org site would have to > store the private keys for logging in to those other sites. > Doable, but an extra step. The configuration overhead is symmetric for each pairwise connection, so I'm not really convinced this is a con so much as a policy decision. I probably shouldn't have framed the discussion with a half-baked pro vs con list in the first place, though :P Anyway, security-wise, the pull model implicitly delegates trust out to each of the mirrors. If any of them are compromised, then up to any (not unheard of) rrsync bug, us.metamath.org is hosed. Controlling connections with ssh keys implicitly centralizes control of the mirror list into the main server; so from a purely "maximize security of us.metamath.org" perspective, switching to a push-centric model simply makes this explicit and lets you remove attack surface area on the main site. Anyway, modulo other constraints, in my "make everything stateless containers" world, the default tends to be to avoid polling as much as possible, so adjust priors accordingly. All that said, thanks for all the good work! Cheers, -- You received this message because you are subscribed to the Google Groups "Metamath" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/metamath/39A9QJAUKTSG3.2CF7Z2NFL1KRS%40wilsonb.com.
