Want to take part in these discussions? Sign in if you have an account, or apply for one below
Vanilla 1.1.10 is a product of Lussumo. More Information: Documentation, Community Support.
I’m considering disabling atom_with_content for the main nLab. It would be very easy to replace this with an ATOM feed generated daily from the database. This could, potentially, take the place of “Recently Revised” as well. The only thing that we would lose by doing this, as far as I can see, is the instantaneous nature of these pages. Rather, they would switch to being updated once a day.
However, I may have missed something, or people might use these pages in ways that I haven’t anticipated, so please let me know what you think before I enact these changes.
Hm, could this also be the reason for the frustrating experience that I am having, that the Lab tends to hang especially when I start working on it? Because, let’s see, is this saying that some processes related to atom feeds tend to start eating up resources as soon as new entries are being created?
I think so, because every time a new page is created or edited, the atom feed goes out of date and needs to be regenerated.
Okay, good that you have identified this!
I am strongly in favor of you “enacting these changes”, then.
I used to like having fairly instantaneous feeds, but certainly could live without it.
I wonder if there is much difference if you updated the feed once per day or 12 times per day? How heavy of a load is it to update the feed? I definitely don’t think the feed has to be updated with every single edit, but every 2 hours would be nice if not too much trouble.
I have sometimes used the instantaneous report on Recently Revised, but not the ATOM feed, so I have no objection to disabling it.
If disabling Recently Revised would improve performance, then I can live with that too.
Certainly, a two-hourly update shouldn’t be two much of a disruption, if anyone needs to use Recently Revised as a feed, rather than a daily digest.
For the moment, I’ve redirected the nlab’s atom_with_content feed to the atom_with_headlines version. Please let me know if this breaks anything.
I never used atomfeed whatever it is and always use Recently Revised to check for recent changes (unfortunately the ouput goes to far in past, what is good for perosnal labs where few changes happen but bad with too long lots on the main lab – maybe two versions should exist, RECENTLY revised, pages and the list of all pages with last revision indicated chronologically (what seems to be now). I use this for including watching for spam, looking for my recent edits when reporting latest changes (I often do not report latest changes and then at the day make one compact entry – say within Zoran’s new entries – on the main changes in the day) and remembering the names of entries where I for somebody else) put some material recently in last few days, that I remember the material but not the page name, and sometimes just for curiosity what my colleagues think about these days.
Sorry for being uneducated but I do not understand if the software needs to check the very database for the changes in last day or so. This would look unreasonable. Why not just do it with messaging: that whenever an entry is changed a message gets generated and recorded to a daily list and if the entry exists on the list for that day, then removing the old message for the same entry from the list. The list of current changes is far shorter and easier to manipulate than the main database. This would require just a message in the change of page process and one update per message and no looking into the central database at all.
Sorry for being uneducated but I do not understand if the software needs to check the very database for the changes in last day or so. This would look unreasonable. Why not just do it with messaging: that whenever an entry is changed a message gets generated and recorded to a daily list
Maybe we had touched on this before, in previous discussion: my impression is that this is generally the reason for the fact that the instiki software does not scale and that we find outselves turning off all its features: at its core, it is apparently not programmed with wikis of more than a handful of pages in mind.
… which is maybe not too surprising: if one looks around on the web, one sees that instiki is being advertized as being easy to install . That’s apparently its main selling point. No wonder that we are running into trouble with it, I think.
I have mentioned the following before, but received no replies: I’d be willing to pay a professional programmer (or team, or whatever it takes) to seriously look into the instiki code for all the problems that we are having. Currently all we are doing is iteratively switching off features of the software. That is better than it breaking all down, but in the long run is rather paradoxical.
But I don’t know how to go about hiring some programmer to do this. Does anyone think it would make sense? Does anyone have experience with this?
1 to 11 of 11