I didn’t write any code today, but I did give moderation and renaming a lot of thought off and on. The conclusion I’ve come to is mimicking move via copy/delete is not a direction I want to explore with Forust. Deleting is only for bad content at the gateway, and never for any kind of moderation. Copying is out entirely, because it’s difficult to separate the redundancies after changing the primary URI of a bough. I started to come up with the logic for ignoring the leaf artifacts associated with the previous URI after a rename and that’s when the bug made me hit this realisation.
What to do? It’s Thursday night and tomororw is the last day for coding moderation (I suppose I could do some on Saturday after the marathon).
I can’t base moderation around the URI. For one there’s this huge bug with duplication and for two, it just feels dirty. I will probably want to change the starting URI to be a date, and then it fucks up all the logic based on a “new/” prefix. Besides, who wants to give someone a URL that has “new/” in it? That word just screams temporary, which is not the impression I want to give with the starting URL’s (that redirect even after a move has occurred and thus are permanent).
It’s difficult to come up with a list of new URI’s to moderate, but this will have to be done via leaves and thus the page needs to be entirely loaded to determine if moderation is to occur or not. I haven’t reached the CRON stage, so I don’t have any task which will be periodically scanning. However, even then I don’t really want to do that, because it implies some kind of nominal delay that will only grow as a site gets larger and larger. Instead, a more naturalistic approach seems best.
Every time someone views a page with unmoderated content, the PHP will append the bough URI plus the section URI (which could be one in the same) to a text file. This will be done as quickly as possible and with the understanding that an entry might not be made due to locking. The filename will be based on the current date plus the hour. The first (rough cut) moderation tool will randomly pick a section URI from the oldest file, display the S3 object and its meta data, and move on. The picking part will remove redundancies when processing in memory (not in file) and if there’s no more unmoderated sections left, it will delete the file.
Not exactly a polished approach, but it allows the moderator control over both sections and boughs.
Speaking of that separation, this particular tool will need to understand the difference between a bough URI (e.g. bough and section URI are identical) and a section. It will then display different options whether deleting/categorizing a new page or hiding a particular bough’s content.
I don’t have any plans to do a tool for comment moderation. Rather, individual users can hide/shown comments at their will (coded during the rating/customization stage) and if enough do this or a moderator does this, it will take effect for anonymous users.
