(Lots of stuff in here, click "whole post"!)

> How about listing what dmpk2k or you have done already?

Truth be told, I haven't even looked over his contributions yet. I'm doing some work on Kareha first. He did bandwidth load balancing for Wakaba across several servers, and image file archiving, at least. Plus some proxy checking and other goodies.

> Split threads and posts into separate tables. You're repeating the lasthit and parent column over and over.

Bad idea. Adds a lot of code complexity without adding any new functionality. The current solution is simple and robust.

> Automatic closing and moving of threads that do not get any activity in a certain timeframe (based on average activity frequency of the board)

This is nearly impossible to get right, and I don't think I'm going to try unless someone can think up a reliable algorithm that uses the data that is availble (not much).

> Reintroduction of "Marked for deletion (old)" (it's just handy to have that)

I tried several times, and concluded it wasn't worth the code and database overhead it would take. This feature is relatively easy to implement for Futaba-style post number limited boards (and Futaba implements it really stupidly), but it gets tricky when you have different deletion modes and want to do it right.

> Prune-limit mode that is defined by number of files or size sum of files on a board

Size limit is already implemented. I might add file limit, but I'm not sure it's all that useful, when you already have the size limit.

The rest, I agree with, and I will try to get most of it done. I'm sure there's some more stuff hidden in old threads, though!

Too late! Already released!

Oops, here's the screenshot. orz

Wow, >>243 sure looks like shit in Safari. What the hell? Looks right in Firefox, though.

> Also: I just noticed that "¦" in tripcodes will work correctly but turn into "�U" through the cookie on /soc/ but not on the sandbox.

This might have been worded a bit akwardly. What I meant was: Tricodes work fine with ¦ on both the sandbox and /soc/&/sup/, although the latter boards will strangely turn the ¦ into a U? after the reply button was hit.

Thanks for the links at the top. Previously, I had to search for those threads over and over again if I wanted to find them.

> the only boards that use them are image boards where you have to load images anyway.

Correction: http://www.akatsukimanga.com/kareha/

> To more closely resemble the 2ch look, how about prefixing thread title headers in the main board page with a 【position:postcount】thingie?

I find the "1. Thread title (1000)" format much more readable in the post list. And for the main titles, I don't see any value is putting the position in there. That serves no discernable purpose.

> And as suggested before, the navigation links on the bottom of individual thread pages should include "Previous 100" (ie, all posts before the first post in the URL) and "Next 100" (ie, all posts after the last post in the URL).

They already do, but only if there are enough posts in the thread for this to make sense. Or, try a short range like 23-27 to see it in action.

> The "First 100" link should also be removed from the bottom of individual thread pages, and there should be a link to to thread-list included below the reply box of each previewed thread on the front page.

I've been wondering about the justifications for which navigation links should go where. 2ch has it pretty much worked out, I'm sure, but I don't quite see why there should be a "First 100" at the top but not at the bottom.

> Change "Del" links to widget buttons.

Would be very ugly. Those buttons are big.

> In order for the CSS selector not to take over the entire header, how about turning it into a drop-down menu?

I was meaning to do that from the start, but there was some problem with gettting it right. I forget what exactly.

> The same could be done with the Admin functions (appearing only after one correctly inputs the password), placing it on the right side of the board and thread title headers (this would also allow admins the convenience of deleting and permasaging threads from the front-page).

Squeeks would prefer to have a separate script for admining. I'm not sure which is the best approach here.

> and would something like this work (given that all boards share the same root directory)?
> >>>>sup/1129153864/1-100
> >>>1129153864/1-100

Maybe, but I don't see the value in adding code for this, given that you can just paste the URL in there.

> P.S. When you mentioned serving dynamic pages in >>46, were you referring to individual thread pages? As I mentioned before, it'd be nice to make the front page as dynamic and flexible as thread pages when it comes to viewing options (via PATH_INFO).

The front page gets lots of hits. This would drive up CPU usage something fierce.

> Oh, and please bring back MAX_LINES.

I still don't think it serves any useful purpose.

>>70

?

> Personally, I find the reverse order listing, as well as the random order listing, to be a bit silly & useless.

Well, no, duh, that's the point. They're jokes.

> The only useful bonus feature here seems to be the comma range seperator, but it seems even in that case there is not much benefit to it (saves 1-3 links in the average case that it is needed, which is rare to begin with).

On the contrary, it's very useful when referring someone to a specific discussion in a thread where several discussions are going on, since you can make a link that only shows the relevant posts. Not just on the board but when linking to threads elsewhere.

I meant Remote host adress instead of IP.

durr hurr

>>70

?

> Personally, I find the reverse order listing, as well as the random order listing, to be a bit silly & useless.

Well, no, duh, that's the point. They're jokes.

> The only useful bonus feature here seems to be the comma range seperator, but it seems even in that case there is not much benefit to it (saves 1-3 links in the average case that it is needed, which is rare to begin with).

On the contrary, it's very useful when referring someone to a specific discussion in a thread where several discussions are going on, since you can make a link that only shows the relevant posts. Not just on the board but when linking to threads elsewhere.

> It's a link, it screams "Click me!".

There's something to be said about obsessive-compulsive... >.>;

Here's a fun little game for you all!

I'm looking into adding support for using HTML markup in addition to WakabaMark, but since most boards use XHTML, I can't just let through any old HTML, and most people can't write well-formed XHTML. Also, I don't want any cross-site scripting going on. So I've tried to write a piece of code that takes any horribly written piece of HTML, sanitizes it by removing all tags and attributes that are not an approved list, checks the attribute values, and turns it into well-formed XML.

Now I'd like to see if anyone can break this. The objective is to get some Javascript onto the page, or making the page break in Firefox (or any other browser that parses XML strictly), or otherwise causing trouble. Have at it!

http://wakaba.c3.cx/test/sanitize.pl

>>214

Point taken. I'll add it as an autoclose option.

> Another topic: since dynamic pages eat up CPU in order to rebuild pages according to URL parameters, what would be the likelihood of the current dynamic thread subpages having a significantly adverse effect in this aspect if a board were to grow to 2ch-sized proportions?

The effect would be miniscule in comparison to the huge increase in bandwidth that would result from sending the entire static thread pages.

The "entire thread" link can easily be changes to link to the files in /res/ instead of going through the script, but that would make it somewhat less convenient when you want to consturct custom URLs, so I haven't done it.

> Also, let's put out a partition to kill secure tripcodes (unless they originated from 0ch/Futaba)

Why? Even if 0ch or Futaba implemented secure tripcodes, you wouldn't get the same secure tripcode there as on another board. That's the nature of the security.

> captcha (until we find a way to implement similar functionality without requiring it in the form of a GIF/PNG image)

That's even more non-sensical. Nobody on the entire internet has figured out a reasonable way to implement captcha except by using images, and the only boards that use them are image boards where you have to load images anyway. And finally, they aren't just there to annoy you, people do actually try to flood boards, and they are stopped by the captcha.

> And is there any practical way that Kareha can be modified to run multiple (even nested) boards in a single installation?

Not without doing a lot of changes throughout the code, and not without breaking current installations.

>>148

>5) Seperation of sage et al from the email field to something else...

This is kinda what I had pushed for earlier in >>52. I think that separating the sage (aka, "don't bump"), fusianasan (aka, "show IP"), and ID:Heaven (aka, "no ID") functions from any particular post elements in the main scripts would be ideal for implementing Kareha in systems where inputting a certain string to trigger these functions is not intuitive (ie, every board outside of the 2ch/Futaba family). These trigger strings (S_DONTBUMP, S_SHOWIP, S_NOID) and their assignment to a certain form field input could be instead implemented individually in each template.

>2) Have the string to sage and fusianasan defined as a constant in config
>3) A specific string for ID:Heaven instead of anything in the email field

As I mentioned above, this would better work if they could be modified within each template in the list of string variable definitions.

>4) Cookie preferences such as "Don't use expanding textarea" which leaves it small or big.. or another option for that choice as well; an option to not save Name/Email automatically; anything else that is useful?

I like this one, as far as saving name and e-mail inputs go. I occasionally browse 4-ch at school, and it'd be nice for just an option to clear cookies when you're done and don't want anyone else to use your name, e-mail, and deletion password.

What the hell is RENZOKU?

P.S. >>151 is RMS

>>294 Hey I like the new formatting bit. Should it collapse back down if you click away or if you click the "More options..." bit again, like the text box?

Just a thought. This setup is easier and more obvious than using the link field, with "AA" or "Wakabamark". BTW, I just realized that was a pun. Boo! Hiss! Not punny! :)

Whoops, sorry. I read "close" instead of "permasage".
Permasage on filesize seems pretty silly, yes.

I've returned from the world of the dead, with old forgotten...suggestions! http://wakaba.c3.cx/sup/kareha.pl/1109447905/l50

>-Scaleable administration (ie, [variable permissions for different passwords])
>-Forcenick and/or force anon for [specified IPs]

>>184
If people are going to decide to use custom names for paramaters, then there isn't much you can do about it anyway, or is there?

>>116
Good question! I tried to find out myself but just found some interesting but rather unhelpful links:
http://d.hatena.ne.jp/keyword/fusianasan
http://info.2ch.net/guide/faq.html#G5
http://ansitu.xrea.jp/guidance/?FAQ1

PS: I always wanted to say this: The # anchors on the TiddlyWiki automatically scroll me (FF, 1.0.7) just below the actual text box of the entry. Is that a bug, a feature or... ?

It's also more markup when even the existing one isn't working as well as it should.

Anyway, test with |

rel=nofollow for internal links as discussed in http://wakaba.c3.cx/sup/kareha.pl/1127092367/