With all the hullabaloo in the tech world recently over the replacement of traditional hierarchical filesystem layouts with metadata searching and filtering, I've been entertaining the idea of only using a single copy of Kareha for an entire site, by putting all threads into a single directory (each with a general category assigned), and then having the front page and backlog change dynamically according to viewing options with regard to these categories.
For example, I'm creating a new thread about Hurricane Rita, and there's a pull-down menu with a list containing "News," "Games," and "DQN." I select "News" and post as usual. Initially, a new un-cookied user will be shown "All" threads, which includes my hurricane topic, but they can narrow these down by selecting one or more categories (via another menu in header.html or something) and filtering the rest out. One logical aspect of this would be to cookie the user's current category selection for both viewing and creating new threads.
One of the more obvious advantages in this is that it would remove the need for frames and restore precious screen space taken by the navigation bar on the side. At the same time, it would remove the need for multiple instances of BBS software on the same site.
On the other hand, this wouldn't work well at all on a site like IIchan where the boards are spread across different servers, unless a distributed approach is implemented (which would be a whole 'nother project for Kareha I guess).
Of course, I'm guessing that the backend of the software would require some fundamental restructing to make the front page and backlog as dynamic as the individual thread views are. This, in turn, could pave the way for more fine-grained personalized viewing options on the front page. The main thing I love about Kareha is the fact that it doesn't use SQL software, but I don't know if this idea would still be feasible that way.
Any ideas?
What kind of site is this? A blog?
My idea: See if you have any input for this:
http://wakaba.c3.cx/sup/kareha.pl/1104757670
Well, it certainly would be possible to do this, with a bit of hacking. You'd just have to add some new task to the main program that builds a dynamic front page and outputs it directly. Using the templating code and the fact that each thread contains a section with metadata at the top where you could stuff your categories and such, it should be straightforward enough.
However, it may be that you'd run into performance issues if you used this on a site with lots of visitors. It might need some sort of caching system, which would be a lot hairier to get right...
>>4
So the same methods that allow me to view a static .html file in /res dynamically would be more difficult to implement in a universal front page? How would the performance issues be different from the case with individual thread views?
The performance hit comes from the fact that you have to read at least the first line of all thread files to build the front page. The thread views just need to open one.
With any luck, the OS will keep the thread files in the disk cache, and it will be fast enough, but without testing I couldn't say.
Alright, new question.
What characters are valid in Perl for separating different types of PATH_INFO URL parameters? For example, if I want to state that the support board frontpage should display threads 4 and 15-7 (reverse order), with the last five replies of each thread and each post abbreviated to the first 20 lines, I could type something like:
http://wakaba.c3.cx/sup/4,15-7:l5:1-20/
Replace the colons with whatever valid characters can be used for this separation. Is there any way that could work?
You just get PATH_INFO as a string. It's entirely up to you how to parse it. As long as you escape URL command characters (like ?), you can stick pretty much anything in there.
Well, do you know of any traditional UNIX-type syntax for defining types of parameters between a certain defined character like that? :) Just wondering which one you would use...
／⌒ヽ
⊂二二二（ ＾ω＾）二⊃
| / AG-E
（ ヽノ
ノ>ノ
三 レレ