Ideas/Suggestions on distributing updates

I have been trying to come up with a good way to distribute updates to my customers.
Such as I mad a minor change or bug fix to a script and don't feel it is fair to make someone who has purchased the script to buy a new one when the change was fairly minor. I would think llRemoteLoadScriptPin would be ideal, but if I am understanding right I would have to have modify rights on the object owned by the customer before this function will work. Of course I would have to previously set the PIN number as well on the customers object.

My next thought was to create a dispensor that the customer would touch to initiate the process, they are instructed to drop the script they wish to update into the dispensor. My scripts are no mod and I have been using version numbers in the name, so I could compare the dropped script to the updated script and hand out the appropriate one. But according to the wiki information on llAllowInventoryDrop you can't drop scripts into objects.

I do sell my scripts in a basic prim as a package do that they get the script, any configuration cards, and instruction card. So the customer isn't restricted to the prim it came in. My scripts are permissioned in one of two ways: no mod/copiable/no transfer or no mod/copiable/transferable.

So has anyone attempted this, have any ideas or good suggestions?

The problem with any sort of 'drop here to update' updater is that they can be tricked. All someone has to do is get a full perms prim (or script) of yours and then they can pass it off as whatever they're trying to get from you.

Honestly, I don't think there's a good way to do this for old products besides manually.

There are many methods of updating your products (semi)automatically if you plan ahead for them to be updated, of course.

(my thoughts)

* Overview
- There is an updater object which has a notecard describing the objects in the system and which scripts they use. The updater script in the updater object uses this notecard configuration data to look for scripts within itself and transfer these (i.e. update) out to the system objects. The script transfers the appropriate scripts out to root objects which are described in the configuration notecard. Each root object has a rootPrimUpdaterScript which then transfers out appropriate scripts to the child objects.
- The concept would be if you wanted to give someone an update you would give them updateObject_v12 which they would then rez in their sim and run to perform the update (they may have to run this once in each sim where part of their system exists).
- The other use for this system is script developers to assist themselves updating scripts during debugging.

* Updater Configuration Notecard Line Syntax = ScriptName, RootPrimNamePattern, RootPrimUsed?, LinkedPrimNamePatter
- ScriptName = name of script
- RootPrimNamePattern = object pattern name for root prims within the system (e.g. GATE*). If the system has a lot of similar objects in it's design the wildcard approach can assist in minimising the configuration notecard for the updater. See assumptions below too.
- RootPrimUsed = This will let the "rootPrimUpdaterScript" know whether, after it is finished distributed the script out to the child prims, whether to keep the script within the root prim itself or delete itself
- LinkedPrimNamePatter - this is the object name (with wildcard support) for child prims, to let the "rootPrimUpdaterScript" know which child prims to send the script to
- If there is a "//" at the start of the line then ignore this - this allows the creator to maintain a complete topology of his system/game within the notecard configuration and just comment/uncomment lines to dictate which scripts should be distributed.

* Object/UUID Discovery
- OPTION 1 - The above approach assumes that the updater script would "sense" for root objects which match the rootPrimNamePatterns and obtain their UUIDs in this fashion. This limits the updater working range to 100m. One would need to be careful that only objects for that instance of the system/game were picked up (e.g. if there was more than one instance of the game rezzed together sidebyside)
- OPTION 2 - Drop the ability to use a wildcard here and then use your already existing (hopefully) communications layer/scripts. What I had in mind here is the use of DNSName approach and OBJDNS to resolve DNSNames to UUIDs. The updater script then just passes the object DNS name, and domain name (which indicates which instance of the system), to the comms script which then returns the UUID. IM asking for a landmark to my plot as I have a UML diagram displaying the concept if you want. An advantage here (aside from the advantages to the game/system itself) is that the updater object would only need to be run by the owner once in each sim, as the limiting factor would then only be the llRemoteLoadScriptPin (as opposed to the sensor).

* Mechanisms
- use of llSetRemoteScriptAccessPin, llRemoteLoadScriptPin

In reply to a Kage Seraph drop-to-update script posted in the library, I submitted a revision which includes a 'secret code' in the text of the email message to the update server.

I asked at the time if anyone know of a reason why that would not be reasonably secure, but got no replies...
... so as far as I know, if the boxes you use to distribute scripts include their own no-mod, no-trans update-on-rez scripts, then that would be a reasonable way to distribute updates.

Before you update, you establish a protocol for the old version of the script to accept updates. This could be as simple as pre-arranging a large effectively-random script pin, or as complex as diffie-helman key exchange.

Then your customers rez the old object next to the updater... and it does whatever you want it to do.