I've been hearing people complain about the disadvantages of Listeners (lag, 256 char limit). Here is what i've been doing to combat these demons.
For a generic rezzer (i use my SetPrimitiveParamsAdv in it) i link the new prim to the rezzer, send it what the prim is to do via linked message; and finaly unlink (at which point the prim does what it was told). I use TypeCSV2List & List2TypeCSV for transport of the list. I set llSetRemoteScriptAccessPin and then later use a sensor to give die scripts out (viral derezzer?).
Resulting in no listens being used.
For a vehical i needed to tell a few prims that the vehical was moving. One way would have been to poll the physics flag constantly, or another use Linked Messages. Linked Messages are just as bad in vehicals as Listens; the more you have of them the more likely your vehical is going to freak out on sim crossings. My solution (which i now think was the wrong one) was to constantly poll the name of the second prim of the vehical. This prim in turn had the only link message listener in the vehical; it's job was to listen for vehical starts and stops. Polling the name of the second prim might be sim unfriendly but it makes sim crossing nicer.
For an upcoming project involving many attachments; the solution for attachment validation comes down to constantly polling the names of prims in the attachments via llKey2Name.
Alternatives:
llMessageLinked
llKey2Name
llGetLinkName
llSetObjectName
llSetRemoteScriptAccessPin
llRemoteLoadScriptPin
Helpful functions:
SetPrimitiveParamsAdv
TypeCSV2List & List2TypeCSV