Product Updating & Duplicates

[Tommy Rampal]

Hey all,

So I am currently working on my product and how it updates when a revised version arrives.

My main problem is how to avoid unwanted duplicates through copies (aka. a customer updates one old product many times). The system right now grabs the latest version number via. HTTP request. For the convenience of the customer I want to try and make the updates remote, i.e. the product sends an llEmail to the server (with the server UUID grabbed by the HTTP request) and the server sends the new copy to them.

Now here's where the confusion lays, we have one new copy and the old copy. What would be the best method now? I was thinking... upon attaching the new version, it asks the owner to drop the old version to the floor; through this the old version sends a verification and deletes itself using llDie (the product is no copy). Is this a viable method or does anyone have any better ones out there?

[PeterCanessa Oh]

Sounds good in outline.

Some things that aren't clear just from the post - although you've probably thought them through.

1. Deliveries don't always succeed or are rejected by mistake.  Neither your old attachment nor your server can be sure that the new version has arrived unless/until the customer attaches it and it sends a 'dear mum, arrived safely' message back to the server.
2. Unless/until then each time they log-in or attach the old version it will, presumably, contact the server, find out there's an update and ... what?  Request another copy be sent?  Nag the customer to delete it?  If the customer really hasn't received the update you don't want them deleting the old one.  On the other hand you don't want them getting multiple copies of the update.
3. It's an attachment.  How many copies could one avatar legitimately use at any time?  Presumably one (or a pair, if it's shoes or something).  So why do you care how many copies they have in inventory?  Make it copyable and no-transfer then however many they might have they can only attach one at a time anyway.

Hmm, I'm sure there's other things to consider but that'll do to start with

[Andromeda Quonset]

I don't think I would like that.  I mean, frequently, I find an updated version unintentionally less functional for me than an old version, and will generally continue to use the old version.  Some products have an accumulation of customized settings, and the makers of those products offer a method of transferring that information to the new version.  If your product has such functionality, you probably don't want it to do an llDie until that is complete, and verified.  I just updated a product last week, and the update failed the first time for me, and I had to repeat the procedure.  There are popular update systems available, and I use one for my products.  To prevent too many unwanted duplicates, it has a timer implented so that 12 or 24 hours have to elapse before the update request will work again.  Having a customer acquire multiple versions of a product can be unwanted, and I usually make these no-transfer.  It is particularly unwanted to have a customer angry with you becuase the update stystem malfunctions due to lag or an error in the update system, leaving the customer without a working product, and telling all his firends that he can't recommend your product.  Usually in colorful language.

[Tommy Rampal]

Pretty much, the new version won't function without 'eating up' the old version, so the updated copies will uniquely have an 'update-version' boolean placed in the script, which will be set to false upon the update being successful. Newly purchased products will have this set as false by default.

I'm unsure about the optional updates, because sometimes it is nessecary. E.g. Base64 password changes (the form of encryption I'm currently using) to fix some sort of security breach, or communication changes (e.g. change of commands or their structure). Unless I had two update functions, with a 'force-update' toggle in the HTTP side of things: so if it's false, the user has the option to continue.

Regarding the failed delivery, it's the same concept of the Secondlife Marketplace - how do they deal with failed deliveries?

The finished product will be No-Copy and Transfer. So unwanted copies could mean lost sales!

[Void Singer]

if you require an update for compliance with something or another, then the standard method that I've seen used inworld is to disable the old copy when it finds a new version (it should also request a send on the new version). then, any time after that, if it rezzed in a disabled state, it should just request a send on the latest version.

since you are using a -copy+trans setup, I would assume that new object will arrive in the form of an updater object that modifies the original? that would seem to be the only secure way to handle that.

if updates are optional, you might want to include some type of menu command to have the object ignore optional updates so that the user isn't nagged to death every time they use the object.

[Tommy Rampal]

Server side I was thinking of having two values: one version value for the required update and one version value for the optional update. Depending on the object's own version value, it will display the message accordingly (with the required message overriding the optional message). Client side, a Boolean for optional updates will be set to false once the user has initially seen the update message, but I will have it that an icon represented as a prim appears in the HUD, that once clicked it re-shows this message. That's my take on the optional vs.. required update system.

Now my take on the old vs.. new update method (for required updates), is the user has decided to undergo an update, it leaves it in a permanent 'Please update/drop' state. The only way of getting out of this is that the script is reset (back to general use) and the HTTP request fails (in which case it times out and carries on as normal).

I will recover the game statistics either: by the transfer from the old to new (sends the statistics as a CSV with the confirmation) or I can do it via. Backup (grabs the stats from my database).

What do you think of this concept? This way the user can have many updates from error, but will never work (one will only work) as it will require the old version to activate. Once this has happened, the user can pass on the product through gift or sale, assuming the script isn't somehow reset.