Just to follow up while im suffering insomnia, if you look at the code for Super Search the text block at the top (in the q()) has 4 columns. the 2nd through 4th columns represnt nodetype, section abbreviation, and section name. (The section name is optional and is only needed if the abbreviation!=section name). We should turn this info into a Setting and expand it to cover all nodetypes. (Its a pity nodetypes don't have a way to store this...) Then this can be used for whatever it is we end up doing.

As for id and type, i want the Id for the same reasons Bart outlines. I want the type because for a pmdever such information is very useful. I want the id and author in a raw form because for various things such information is useful in a n "un-urled" form. Eg, making a nodepin you need the id, currently its a bit of a pain to do.

And yes ultimately i think much of the redundant info would be better off in a single nodelet. Even if folks want it the other way I still want that nodelet. So I think the best thing is to make a htmlcode node that is used to provide this info. It should adjust itself appropriately based on parameters so it can be tailored for reuse in other nodelets if thats what people want, but it should also handle various logic like group memembership and $VARS determining what people see. Essentially the nodelet i want would have all the special links at the top of the pmdev nodelet, and the stuff at the top of each node, along with assorted related bits from the other nodelets. Presumaby this nodelet would just a be a special case of the htmlcode node i have in mind.

Pesky time keeps disappearing though so I havent got a prototype put together though.