>The effect would be miniscule in comparison to the huge increase in bandwidth that would result from sending the entire static thread pages.
How about a config.pl parameter to split up thread subpages into X posts per page? The navigation links already use 100 posts per page for practically everything except "Last 50 posts".
Hmm, I just remembered: >> links would not work at all with static pages. Not good.
>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.
Right, I guess it was dumb to mention 0ch/Futaba in the first place. The point is, as you said yourself, tripcodes are a gimmick, and if someone wants to maintain a persistent identity across multiple boards and sites (ie, everyone here with a tripcode), they have no choice but to use ordinary tripcodes. Secure tripcodes are useless because they limit your identity to a single board, supposing each board/site's cipher key is different -- which it should be, since that's the point of having a secure tripcode in the first place. No one should be so paranoid about a tripcode that they'd need to have a different one per board/site.
>Not without doing a lot of changes throughout the code, and not without breaking current installations.
Shouldn't we sacrifice some backwards compatibility for a more robust and scalable design? It might even be possible to provide an upgrade.pl for old threads.
>You could only trigger the functions in a specific format, say...
That's a cool idea, though for now it would have to be left alone if we want to keep Kareha compatible with 2ch/Futaba conventions.
>>195
Exactly. The methods and the effects of saging a thread are separate subjects.
P.S. I recently discovered "rXX-XX" for threads in /soc/. How exactly does this work? From the sound of it, it's supposed to randomize the post order, but when I hit refresh I get the same order.
Okay then, for starters, how about the closing message to exactly look like a post (although it's sad it won't be accesable with >>1001)?
I think you're a bit nutty, >>350...
> 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.
Wow, >>243 sure looks like shit in Safari. What the hell? Looks right in Firefox, though.
Semantical nitpick: shouldn't the "Page top" link be called "Thread list"?
> You mean requiring SQL software, or just making backwards-incompatible changes that would screw up old threads?
I mean, needing to alter the table that is already in the database. I don't want to try to do that any more than I have to, as it's pretty hard to get right in a database-independent manner.
> Are you only referring to flooding and spamming, or also trolls and flamewars?
Yes, only flooding and spamming. Trolling and flamewars are not a problem one should use banning to try and solve.
> Finally, out of curiosity: how much of the functionality in the .js file do you think could be properly implemented into a new or existing perl script?
Well, if you serve up dynamic pages, you can do the form-filling on the server, but that's about it. The rest is dynamic stuff.
> Making them configurable from site to site is really dumb, because it would create an unthinkable usability mess.
Why? Let people figure out things themselves, if they are so keen on changing their keywords. They can get together in their own webmaster threads and figure this out. I don't see why this should be solved here.
Of course I think this is a dumb idea in the first place. Nobody needs to know what fusianasan and sage are. Write a FAQ with two sentences about it and/or let your oldtime users tell newbies. Two frickin' words, and you people talk about it as if it were something like making up a new system of romanization!
> Then why not simply boil it all down to the comment field, with trigger strings for inputting the name, e-mail, sage, ID:Heaven, and fusianasan? You can get a lot more minimal with the current interface.
That's a bit too much. You want to talk about sage and fusianasan in the comment field, not trigger it with it.
I suspect you are joking here, though. Design is about what you can take away and still remain optimal conveniency/efficiency on the user part, not about taking as much away as you are technically capable of.
>>327-328
All of this would be better handled by an external application. I think you are putting way too much work into user gimmicks as it is.
More options means putting more buttons, links, etc. into the interface. I am still bothered by the "More options...", but I am just a text purist (doing my fair share of AA, though) anyway, so meh meh... ( ´・ω・`)
> Wait, why should l50 links be indexed/cached?
Because the only way for the search engine to find the old threads is to go through the l50 links. I'm taking the advice of >>322 though.
> The CSS in the All threads page is unsightly. Is there a way to properly wrap the outer color border(s) around the table of threads?
You need to explain what you're talking about before I can do anything about that. What style, and what does "wrap the outer color border(s) around" mean?
> I still say that the "Navigation: " text is extraneous when people can clearly see what the links do. Also still partitioning for 0ch-style error pages (with displayed user host and all).
It's there because freefloating unlabelled links look weird.
> Now that we do have filesize indicators in the backlog page of mode_message, do you still find it useless to have the red bold filesizes near the bottom of thread subpages?
They're there, but only if you enable pruning by size.
> Does mode_message now work in PAGE_GENERATION => 'paged'?
No. I'm too lazy to figure what that's supposed to do, and I don't think anybody actually wants to use that in the first place.
> Idea: forced anonymous/sage/ID/fusianasan by IP/thread/board/whole site (some of these combinations already exist, I know)?
There's no database to keep IP data in, and I'd prefer to keep the script completely agnostic to IP addresses.
> Finally, I imagine that the permasage/close/delete functions in kareha.pl will be easily interchangeable among the conditions in post_stuff(). Can you confirm this?
No, because I don't know what you mean.
Text Art's description about auto-linking URLs and >> references is redundant. Not a bad solution with the layout, though (hiding the menu behind "More options..." still bugs me).
The Futaba template is missing the "No File" checkbox next to the File field in the Post New Thread area.
> 3) A specific string for ID:Heaven instead of anything in the email field
Isn't that already an option in the config?
> 5) Seperation of sage et al from the email field to something else...
Strong oppose! I am of the (strong! lol) opinion that the current situation is the one working the best and also that it is widely accepted on almost all similiar board scripts (save for Shiichan and one obscure Japanese discussion board script that I once stumbled upon).
Previous discussion of this can be found here:
http://wakaba.c3.cx/sup/kareha.pl/1102984488/
>>38
Sorry, I guess I should've worded that more clearly. I was referring to the ability for users to delete their own posts. It's counter-productive to discussions when a user deletes his own post and a quick replier later quotes or references it. It also encourages users to be lazy with posting, because they can always go back and hide their mistakes.
> Is it intentional that thread links without a trailing slash
Uh, I was wondering the same thing. I'm not sure. I guess I should fix that.
How about listing what dmpk2k or you have done already?
/-100 shows the first post two times.
Kareha can't use different layouts for posts on different pages, except by CSS trickery. I could add the second colon, though.
Also, I've implemented optional thread closing now, but there's no extra post. That would just be a total mess to implement, and would make re-opening threads annoying, if such a feature was requested. It replaces the posting form with a notice that the thread has been closed, instead.
First thought: It would eliminate the concept of sageing as a protest entirely.
0ch-PHP had this nifty feature where if it was a certain "high bandwidth" time of day, then you couldn't view the whole thread.
Hm... that is kind of useless on a worldwide forum, huh?
But there should still be an option to keep people from viewing more than 100-200 posts, as an emergency way of saving bandwidth.
> 2channel does not do this either by default. It can make browsing a bit more convenient (and I suspect dedicated 2channel browsers to insert & read these in some kind of standardized way) but I don't think that's reason enough to impose it on users by default.
whoops, I misread "postcount" as "posticon". Nevermind!
RENZOKU are the flood detection things... even if they are useless MAX_POSTS_PER_MINUTE makes a lot more sense than RENZOKU2
3) was about a string to trigger ID:Heaven, not a constant for the Heaven part (which is already configurable)
Re: email/link field
Just because it works one way on 2ch/whatever does not mean it is the best way. Having 'fusianasan' as the only way to trigger the effect is just narrow-minded. Functions should have descriptive names to the people using them; should we keep the field names in Japanese because the Japanese have them in Japanese? Having all of the applicable things configurable is something that makes sense, and you can easily have both 'fusianasan' and 'show_ip' that work at the same time. Frankly, the combinations of many things into unrelated fields is a design flaw. What if you want to use a name/trip and fusianasan? What if your email address contains the string 'sage'? What if you want to sage a thread, but have an ID still?
I think the confusion of existing users is worth reducing the learning curve and improving the intuitiveness.
I'm not saying that the default behaviour needs to change, but being able to easily configure the strings used allows for easier localization.
I probably misspelled fusianasan too, why should I have to remember something so foreign?
I don't know if this is a bug or not, but could you change the Futaba template so that hovering over/clicking on a post header doesn't count as doing the same to the deletion checkbox next to it? Same goes for the "[File Only]" area at the bottom with its checkbox.
Gah, I am totally confused about what to do about the admin interface. Separate script? Built-in? Javascript? How do I display the data? I have no idea!