They aren't disable for non-special users. But they aren't particularly useful either.

Right. To be precise, I should have said, "You can add keywords, but since the one other essential feature — keyword searching — is disabled (for non-special users), they're completely useless."* My mistake.

Nolo contendere on the appropriateness of the word "security"; what I was referring to was what you described.

Anyway, it may be that we're a long way off from having a usable keyword system. I still maintain that we need one, whether we get it or not. :-)

(*In fact, it's possible to build keyword-based capabilities off-site, since the xml rendering of a node includes the node's keywords.)

keyword searching — is disabled (for non-special users)

I was going to say that that is a very inaccurate and misleading way of putting it, since I wasn't aware of the feature existing. But you prompted me to search for the feature. Looking at keyword search, I don't see a problem with allowing all to use it (since it doesn't appear to be a resource hog -- though that will likely change before there is a useful volume of keywords; so I hope the node gets much smarter before then), except that it doesn't appear to use placeholders correctly because keywords with single quotes cause a server error (which means that someone could attempt an SQL injection attack, which I doubt could do anything but I'll not enable it until that is patched). Then we'd have a "keyword search feature" at PerlMonks.

I suppose that would be one less barrier to having a "useful keyword search feature" at PerlMonks. And then keywords would no longer be "completely useless" (in your accessment -- I say that they are already useful, if you want to anonymously insult someone by tagging their nodes)... they would be "nearly completely useless" (based on spending some time trying to use keyword search).

But thanks for indirectly but eventually bringing that to my attention. Progress, though tiny, might eventually lead somewhere. (:

Update: Anyone fixing the lack of placeholder use should just remove the query that doesn't use placeholders. It is silly (and inefficient) to do one query to get a list of node IDs and then use that to do another query that selects on both the list of node IDs and on the keyword again. That will simplify the code and even simplify the complex query. Checking the query plan ("describe") would be good at that point, though, as you don't want to "outsmart" the MySQL optimizer.

- tye        

The "/msg author" link was added.

Indeed one of the most useful additions, as of late. And, just to make sure: yes, the current mechanisms do work, and well. Yet it seems both from this discussion and other recent ones like mine itself that there is some desire (albeit no compelling necessity) for thingies that are somewhat intermediate in weight and visibility between the evanescent /msg and a full fledged node. Now, if only could think of the nature of such thingies in a way that would fit all of their possible uses...

Private threads?

Private threads?

Either that or just the opposite: public /msg's. Which, you will tell me, amounts to the CB. But the CB is transient too, logs and recordings notwithstanding. And for what is worth, some like to have turned it off, just like me for example.

But seriously, speaking of adjectives like "public" and "private" rings a bell in me reminding me of a grand scheme I have in mind for web sites like forums, wikis and blogs, which IMHO could be incarnations of the same base mechanism founded on an idea similar to that of permissions on *NIX systems - or perhaps of extended attributes. I'm convinced that with a well though and relatively restricted set of such "flags" one could reproduce the semantics of all those environments, and perhaps create useful mixtures between them. Of course like all grand schemes it has the defect of not being implemented that I know of. In particular I was not thinking of such a beast specifically for PM, but in line of principle...