RFC: Removing Ring Shuffling (please vote)#27
Conversation
Since we removed order randomization we dont actually need the mappings, that was just a way to reason about shuffling the ring without breaking the ring-like nature.
I moved `tbo` to before `haylin` because my site caches it's position in the webring and it's next and prev links for a few minutes at a time. By placing my site between two sites that shouldn't change this will prevent the ring from unlinking temporarily during member adds. My site is not the only site that implements this, Jordan's does as-well, her placement is fine for this though. In the future, members that cache (even for short periods of time) should be placed interior and not on either edge.
|
I am fine with the idea of no ring shuffling: it also made it hard to find specific websites if one person's site was broken. If the positions are absolute, then people can notify their neighbors' site being broken, thus improving ring efficiency. |
|
I think its fun but not super committed one way or the other, maybe decreasing to something like once a month instead if it breaks too frequently? |
|
@Tim70 Actually seems perfectly balanced between my notion of reporting broken websites...but then again, either way works!! The webring has been working quite well either way, so anything that makes it more rock solid as we keep adding people works!! |
|
The randomization has let us catch a few times when people have hard-coded their connections in, that we otherwise wouldn't have found until delinks or new joins happened (which would be a much more annoying time to find out imo). I actually feel myself leaning towards just doing a longer cycle like 2 weeks, I think the effect of forcing people to link properly might be worth it |
|
I think randomization can be a client option. The member returned should be controlled by the webring user by adding a request parameter at the end. |
I'm failing at seeing how this would work? Since everyone would have to have the same topology where they are forwarding. The more I discuss this, the more I am thinking the few minutes of breakage is fine, we could do with a landing page at https://umaring.mkr.cx that shows the currently order for mass browsing sites and that would fix the debug complications with breaks |
|
Upon looking into this further, I think a bigger issue causing the change breakage is that each instance of the site only randomizes every hour (with seed as weeks since epoch). These two instances exist for upgrade reasons so we can do smooth replaces. If this randomization was moved to every 5 minutes they would stay much closer in sync, meaning that regardless of which one a request hits. This would explain why people have noticed the link failures even though it should've only been a short lapse. |
I also advocate for this as a means for people to submit their own websites (tons of non CS people or non web-dev inclined people who rely on Wordpress and such). Actually this can be a new discussion on its own: do we want Wordpress websites or increase the reach of the webring past just this group of CS people?? I'd wager to say why not, but am open to discussion as well. CC: @haylinmoore |
|
re: randomization, ambivalent either way. I like the idea of a longer cycle, seems like a good happy medium. I do agree that a landing page / submission form would be well received, it might be nice to maintain a list of contributors without having to go through every webpage (annoying as the ring grows).
No qualms with including wordpress sites, the more the merrier IMO! |
|
Given that it's basically a tie with a lot of ambivalence aswell I am going to close the PR. If anyone wants to make a PR that adds a landing page, that would be amazing :D |
5 participants
I am currently toying with the idea of removing shuffling from the webring.
I feel that this makes sense because currently the webring gets broken temporarily during every shuffle event, because of the users that cache their positions and neighbors server-side. This server-side loading and caching is in my opinion a good pattern as it lowers requests to the back-end, increases anonymity for people browsing sites on the ring, and lets members have sites that load without extra Javascript. Servers could make a new request to umaring on each request, but that would be blocking.
In addition, randomization of a ring is also not a very common practice from what I can tell, and it simplifies the ring's code (my current PR could even be cleaned up more to be faster).
Thoughts? I think a justification could be made for keeping randomization if people think it's cool, I'm just meh about it, and have gotten a few reports of ring breakage that I suspect were due to it as they were ephemeral.
EDIT: A benefit of ring randomization is it forces people to connect to the ring properly, we find out rather fast if they have hard coded in their links on their site.