>>11547>you should explain hierarchical boards more thoughTo detail my approach to a hierarchical imageboard:
I'm working on a non-standard http server that translates POST requests to writes instead of CGI execution. By default the server would have read, write and exec permission on directories, read permission on all files and directories would be created sticky.
Mounted at the root of the server would be a filesystem, that passes through all writes and on reads generates static pages on the fly (or with some form of caching, idk yet).
Boards would be directories not starting with a special character stripped by the client, otherwise they would be threads.
Either posts would reside as plaintext files and have a header with file references. In this case the client would write to that file.
Otherwise a post would be a directory without write permission, with a plaintext body file and fields or references as separate files, which means it could not be directly written by the server, instead being written as an asynchronous request to a fifo, which has higher throughput and is more secure than a CGI request.
>the SQL for showing it could get pretty complexI hope this makes clear that no tables are involved in the hierarchy. Administrative tasks would be handled by communicating with daemons through fifos or direct file/directory modification.
For bumping, threads would always be named by their last reply and the catalog would be like 'ls' in descending order. Anchoring and pinning could be done by adding special symbols to the thread name.
Post too long. Click here to view the full text.