TWiki Tags discussion

Discussion about tags (functions) as lightweight plugins.

• See TWikiFns
• Also more in TagsAndMacrosDiscussion.
• For free tagging vs. classification, see TagMeDiscussions.

As the code seems to be completed and it's working within the acceptable performance parameters, to try to push this feature forward we need commitment from the TWikiCommunity to perform the following tasks:

• Fully document TWikiFns, specially how to install and activate them from the configure interface.
• Define how TWikiFns will be put in the Plugins web: will they be treated the same as Plugins, or they will have their own category (like Plugins, AddOns and Contribs)?
• The previous point also imply the packaging: How should TWikiFns be packaged? Perhaps following the same structure as plugins make sense.
• Convert some trivial plugins to TWikiFns. I don't know if this is blocking to include this in 4.1 or not.
• Keep the TWikiFns branch up to date with the main branch, so the merging is less traumatic.

If anyone think that there are other tasks to be performed, feel free to add them to the list.

-- RafaelAlvarez - 14 Aug 2006

---

Something in the line of TWikiExpression, perhaps?

-- SteffenPoulsen - 05 Jul 2006

I am very excited about this new feature.

• It is a chance to bring simple plugin type development out to more people people they are easier to understand and implement.
• It is a chance to actually do something about the performance of TWiki instead of just talking about it.

As Richard I am concerned about the TAG name. I would really like to see the name changed.

I know we are several that are concerned about this. We have felt bad about raising critique against this good initiative. And time and has passed and passed without anyone having seriously asked Meredith to consider a name change.

But if the name TAG is to be replaced by something else - it should be done now. And we must recognize that it will require some significant effort from Meredith and the rest of us should be prepared to help out wherever we can.

But I really think we should find another name than TAG. Not because the name is bad in itself. But because it is very confusing on twiki.org where the TagMe plugin has become pretty much worked into the whole site and the word Tag, Tagging, Tag Cloud etc is found everywhere now.

I am very happy to see that you do not totally rule out the idea of a name change Meredith. Allow me to start brain dumping some names.

• Plug - because a Tag is a small Plugin
• Fastplug - because they are supposed to be faster
• Lightplug - because they are light weight
• Fastplugin - Lightplugin as alternatives to above
• Vartag - A twiki- var -iable tag
• Smartvar - A smart TWiki Variable

I'd better stop now. I am not concerned about the inside of the code. The developers can live with the code. It is only in the part exposed to the users and admins that a name change would be required. Developers can cope with internals called something with "tag" I am sure. It is in the documentation and in the Plugins web that the word Tag conflicts with the already established use with the Tag plugin.

-- KennethLavrsen - 05 Jul 2006

I don't use tags on TWiki, in part because I don't find them useful and in part because of the mixed messages that we've gotten on them. (I could cite various comments in Codev to back this up but I'm way too tired and it's way too hard to find them.) What are called "Tags" as in TagMePlugin really should be called labels or something of that sort, since to the limited extent that "tags" and "folksonomy" are currently used in the outside world -- which probably doesn't include the TWiki target audience -- they are used quite differently.

(Note also in SectionalEditPlugin, for example, the use of the word tag to refer to a HTML-like tag, just in case you think I'm just being obstreperous here.

I also don't think that choices made on twiki.org should be imposed on other sites, nor should the fact that a plugin uses a word preclude using it where it makes sense. So I don't find those arguments compelling at all. The core code and the many tags I've written have been around for at least a couple of months now. It's too bad that people apparently haven't been paid attention to what's been going on in DEVELOP or a conversation about renaming would have happened quite a while ago.

I have been using the code and numerous tags in a production site which is now live and I cannot change it now. I also don't have the time or energy to do all of the work involved in the rewriting that will be required.

All that said, Fn would be an OK choice. Had anyone bought it up when it was introduced, I probably would have gone that way since they are, after all, functions, as are most of what are currently called TWikiVariables (a particularly bad choice of names, as long as we're talking about meaningful names.)

I very much appreciate your enthusiasm and support for the idea, Kenneth. You are one of the few people who paid any attention when I first talked about them and expressed support for the idea back then as well. I took your concerns about performance very seriously and largely shifted my thoughts from "ooo, cool idea!" to thinking about improving performance in large part because of your concerns and willingness to spend time to actually take measurements. So please don't read my strong lack of interest in renaming them as anything more than that. There's still too much "ooo shiny!" and too little "gah, slow!" going on for my taste.

(And on a totally different note, I thought that putting a target into a COMMENT tag meant that the text would wind up in a separate topic but show up in the original one. So what's going on here?!)

• Correct except for the "show up in the original one" bit.

-- MeredithLesly - 05 Jul 2006

Meredith has been steadily changing the name to "TWikiFns" - which is more accurate and intention-revealing than TWikiVariable, and less confusing than TWikiTag.

What is under discussion here is not how TWikiFns are used, it is related to whether the functionality should be supported or not. Here are the pros and cons, as I see them.

Pros:

• Much lighter than plugins (no measurable performance decrease from plugging in a tag)
• This is something done very frequently (many plugins are basically trying to do this)
• Makes it easier to configure TWikiFors
• Gives ability to overload predefined tags (though this is already possible if you use registerTagHandler)

Cons:

• TWikiFn implementations have access to internal APIs. if those APIs are used, it makes them much harder to change. Not recommended for the inexperienced/stupid.

-- CrawfordCurrie - 14 Jul 2006

No, you're wrong, CDot. Only TWikiVariable implementations should access to internal APIs. If I've implemented a non-"variable" TWikiFn using core code, then I did something wrong. All of my plugins stick strictly to published API and I intend all of my fns to do so as well.

I didn't find TWikiTag confusing, but I don't use the TagMe stuff either on this site or on mine. And none of the blogs I read use the word tag either. (They mostly say "File under" or "Label it". It wasn't worth the fight, so I changed from Tag to Fn (with some difficulty, I might add).

It should be made clear that Fns should conform to PluginApiPolicies, unless they are ones that ship with the distro and are written by core developers.

-- MeredithLesly - 14 Jul 2006

I think speed measurements will show if it is a good idea to implement so many built-in simple TWikiVariables as TWikiFns. But I have no doubt that as implementations of small plugins they will be much faster and simpler than what we have with the current Plugins.

To mee it is not a matter of IF TWikiFns should be in TWiki. It is a matter of

• Which internal TWikiVariables should be converted to TWikiFn. Instead of a religious war - let us measure. Since it is not something related to skins and javascripts etc. the simple ab tool can benchmark very well.
• Should it be in 4.1? The engine for the TWikiFns - Yes. The conversion of TWikiVariables to TWikiFns - IF the performance is not affected in a negative way - Yes if we can make them stable. Otherwise implement some. And take the next step by step. Then we can start converting some of the simple plugins to TWikiFns and hopefully gain an incremental improvement in performance. No revolusion but the way to eat an elephant is to cut it in small bites and this could be quite a few bites in the right direction.
• It enables much more people to make small smart Fns that they can share once implemented.

What I think Meredith can use is some reviewing of the code from developers - and more feedback. And maybe some help in getting it properly integrated. It is a big mouthfull for anyone to do without some peer reviewing and feedback. I wish I could do more myself. I can test and encourage for now.

And I want to sincerely thank you - Meredith - for spending the time to rename the Tags to Fns (Functions). I do not use "TagMe either on my sites. It was the TWiki.org that was my concern. And that you have 100% resolved by doing the renaming. And I like the new name. It describes - both in short form "Fn" and long form "Functions" what they are. Small light plugins that perform a Function. Like a mathematical Function that takes Variables. Great. Thank you Meredith. I know it was a big job doing the renaming and the community should have raised the question much earlier. But now it is the past.

Crawford, Sven, Steffen, Peter: What steps should be taken before we integrate the TWikiFn stuff into the TWiki4 branch?

We can keep the current 4.0.4 going with hotfix packages - that I can make - so that it is not a big deal if TWiki4 branch is a little shaky for some weeks after the integration. It seems reasonable that TWikiFns could be stable for a beta in end August and release in September as is currently the assumption for 4.1.

-- KennethLavrsen - 15 Jul 2006

There is no religious war, Kenneth, about "converting to TWikiFns". Most of the TWikiVariables are implemented by calling registerTagHandler, which associates a tag with a function. The only difference is whether the function is in TWiki.pm or a separate file. Other than that, there's no change in code. One might argue that there should be, but there need not be and currently isn't. The only hard part is making sure that any bug fixes to TWiki.pm in the variable functions makes it into the separate files as well.

I didn't rewrite the functions implementing the variables the first time and, except for a couple I've enhanced -- mostly notably METASEARCH -- didn't rewrite anything now. The enhancements can be taken out if desired, but I doubt people will want to, since folks have been clamouring for putting attributes like format into METASEARCH for some time.

I didn't name them TWikiTags to be provocative -- I got the name in part from the internals and because I think of them as the "tag" -- the name -- that is associated with the function. (That's #11 in dictionary.com, more or less. As a New Yorker, I also have a mental association with the slang use of the word, which has to do with graffiti. As a web developer I think of tags in terms of HTML. None of definitions have anything to do with blogs.)

It was a bunch of work, but I didn't want this to turn into a battle over naming. I think it's unfortunate that a plugin has co-opted a name, but c'ést la vie. And some of the work was OK in that I moved the necessary code into 4.0.4 rather than having it in develop, which means that I have a stable code base that I can move 4.0.x bug fixes into. And I wanted to contribute something that might make a real difference to TWiki, and this is my best shot. So I just went ahead and did it.

Thanks for the kind words. I know I've been whinging a bit about not being appreciated, but I don't take this as anything but sincere (as opposed to placating me, which I know you don't do.)

-- MeredithLesly - 15 Jul 2006

Kenneth, you asked what has to be done.

• Level 1
  • Existing TWikiVariables inplemented as TWikiFns. This is a sensible refactoring even if nothing else happens, but the functionality is not made visible to the punters. It's not a case of "converting variables to TWikiFns" as a TWikiFn is no different to the current variable impl, as I understand it. AFAIK the only thing that changes is where the impl actually is i.e. a separate .pm versus embedding in TWiki.pm
• Level 2
  • Existance of TWikiFns documented in the release as a viable alternative to plugins. Thus made available to extension authors.
• Level 3
  • Usage and abusage of TWikiFns documented in Plugins web and Codev as part of the plugins model

I think we are ready for a level 1 merge now. However I haven't seen what I would consider to be adequate documentation for Level 2.

-- CrawfordCurrie - 15 Jul 2006

Performance wise I would like to see that the many new .pm files instead of one large does not cause the head of my harddisk to spend so much extra time picking up the individual files that it ends up causing a performance degradation. We cannot accept more performance degradation. However using Fns instead of the simpler plugins can only be a performance gain. But as refactoring of existing TWikiVariables I need to be convinced by actual numbers. So many new individual files that need to be loaded from the disk at each and every page view makes me nervous. Refactoring just for the refactoring is not acceptable if it cost performance. The users cannot care less if these Variables are refactored. That is a programmers wish.

If it turns out to cost in performance we can consider implementing all the Fns for the existing core TWikiVariables in ONE file.

But let us measure first and see if there is anything to argue about (that is what I meant with no getting religious - deciding based on facts instead of belief).

What we need to benchmark is a TWiki4 and a scratch branch that are at the same feature level with any performance affecting bugfixes implemented and with many TWikiVariables converted to TWiki Fns.

Are we able to do that now? The measurements themselves is nothing.

-- KennethLavrsen - 15 Jul 2006

I haven't done documentation because, well, unless there's agreement that they're going in, there's no point.

And, Kenneth, having the variables in separate files means that any that don't get used don't get loaded and compiled. Although I put in ones to preload because they're in patternskin.

-- MeredithLesly - 15 Jul 2006

I would be amazed if you were able to benchmark accurately enough to see a difference in load times between a monolithic twiki.pm and individual function files. Really amazed.

-- CrawfordCurrie - 16 Jul 2006

Question regarding overloading of %FUNCTIONS{}%?

It appears that currently in V4.0, writing a Plugin which registers SEARCH does indeed override the built-in TWiki::Search.pm. This is a very useful thing, being able to modify and experiment with replacements for built-in tags without tons of rewritting.

What will be (or what is) the overloading order, once TWikiFns are released? Will TWikiFns override, Plugins, which override built-in, or some other order?

I am currently experimenting with a different search algorithm using the Plugin method of overriding....Works great! This also gives me access to the afterSaveHandler() for re-indexing when documents change.

-- CraigMeyer - 20 Sep 2006

There are no plans to release TWikiFns Craig. The original developer left the project and noone else have felt the need to pick it up. Probably because all developers felt that other features had higher value and priority. Not because anyone was against it.

-- KennethLavrsen - 13 Feb 2007