Not signed in (Sign In)

Not signed in

Want to take part in these discussions? Sign in if you have an account, or apply for one below

  • Sign in using OpenID

Site Tag Cloud

2-category 2-category-theory abelian-categories adjoint algebra algebraic algebraic-geometry algebraic-topology analysis analytic-geometry arithmetic arithmetic-geometry book bundles calculus categorical categories category category-theory chern-weil-theory cohesion cohesive-homotopy-type-theory cohomology colimits combinatorics comma complex complex-geometry computable-mathematics computer-science constructive cosmology deformation-theory descent diagrams differential differential-cohomology differential-equations differential-geometry digraphs duality elliptic-cohomology enriched fibration finite foundation foundations functional-analysis functor gauge-theory gebra geometric-quantization geometry graph graphs gravity grothendieck group group-theory harmonic-analysis higher higher-algebra higher-category-theory higher-differential-geometry higher-geometry higher-lie-theory higher-topos-theory homological homological-algebra homotopy homotopy-theory homotopy-type-theory index-theory integration integration-theory k-theory lie-theory limits linear linear-algebra locale localization logic mathematics measure-theory modal modal-logic model model-category-theory monad monads monoidal monoidal-category-theory morphism motives motivic-cohomology nlab noncommutative noncommutative-geometry number-theory of operads operator operator-algebra order-theory pages pasting philosophy physics pro-object probability probability-theory quantization quantum quantum-field quantum-field-theory quantum-mechanics quantum-physics quantum-theory question representation representation-theory riemannian-geometry scheme schemes set set-theory sheaf simplicial space spin-geometry stable-homotopy-theory stack string string-theory superalgebra supergeometry svg symplectic-geometry synthetic-differential-geometry terminology theory topology topos topos-theory tqft type type-theory universal variational-calculus

Vanilla 1.1.10 is a product of Lussumo. More Information: Documentation, Community Support.

Welcome to nForum
If you want to take part in these discussions either sign in now (if you have an account), apply for one now (if you don't).
    • CommentRowNumber1.
    • CommentAuthorAndrew Stacey
    • CommentTimeFeb 2nd 2009

    The hopefully unique experience of crashing the n-Lab three times in one weekend (please, everyone, use belts and braces), made me think about mirrors. Admittedly this may be something for a little further down the line and may be more a general Instiki thing than n-Lab, but it may be worth thinking about it now.

    A mirror (or more) would be there so that if the main site crashes, people can still use the n-Lab. Now, having a complete copy of the n-Lab seems a recipe for disaster as there will be conflicts in edits from different sites. However there could well be some value in having static mirrors so that people can still use the n-Lab as a reference, and they can still plan their edits for when the original becomes live again.

    A static mirror can be set up easily by exporting the html. However, it should be kept up to date, probably daily, for which exporting the html every time seems a little overkill. Suitable use of wget can get around this but this still downloads a whole page for a small change.

    Obviously the best solution for bandwidth purposes would be for instiki to be able to export dated diffs. However, that's a feature request and Jacques may like to know whether or not there's any demand for it before investigating so ...

    Do mirrors seem like a good idea?

    • CommentRowNumber2.
    • CommentAuthorMike Shulman
    • CommentTimeFeb 5th 2009
    Static mirrors might be a good idea, but I'm not sure they would be worth the trouble; it depends on how frequently we expect to be crashing the site! (-:

    I'd be more interested in having a reliable backup system in place so that we can be sure of not losing the data permanently in the event of, say, a hard drive failure.
    • CommentRowNumber3.
    • CommentAuthorTobyBartels
    • CommentTimeFeb 8th 2009
    I would like to be able to download the entire database of both current and old edits. That shouldn't be hard to set up, but of course it's big. On the other hand, all one really needs to do is to download, each day or week or whatever, the edits that have been added since the last time, which is not so big but which requires programming to make available.
    • CommentRowNumber4.
    • CommentAuthorAndrew Stacey
    • CommentTimeFeb 10th 2009
    My thought for the mirrors was that it would be best if they were mirrors of what is actually seen via a browser and not a mirror of the whole engine. Since one shouldn't edit a mirror, it doesn't need to have all the wiki software on it. The distinct advantage of this is that the mirror site only has to have a web server and not a full instiki installation.

    Of course, one might also like to have a local mirror of the whole thing in order to work on something offline for a bit before committing the whole thing. That's slightly different. I'm not sure that exporting the whole database (or chunks of it) is going to be allowed as it also contains things like passwords.
    • CommentRowNumber5.
    • CommentAuthorTobyBartels
    • CommentTimeFeb 11th 2009
    Certainly a mirror only needs the current pages in HTML (well, XHTML+MML) format. It's backups that want a database of all edits. (That's only edits, preferably with user names and timestamps attached, not passwords. But if passwords are mixed with edits in the software, then that may not be so straightforward to allow, even if one ignores size.)