TipTracer™ Considerations (technical stuff that might be helpful to know):

(Continued from TipTracer Introduction)

In order for your MHS Donation Jar to be working with the TipTracer system, it must be registered with the server and remain rezzed inworld. This enables the jar to "ping" the server. The purpose for this mechanism is to ensure the web server isn't holding abandoned data for people who -- for any variety of reasons -- are no longer using their MHS Donation Jar.


Q: What do you mean by a jar "pinging" the server?
A: It's a tap-on-the-shoulder to the server to tell it that a jar with a specific object key is still inworld, alive, and running.

Q: What do you mean by an object key?
A: Everything in SecondLife needs it's own fingerprint. That's what an object key (also called a UUID) is. Read Linden Lab's explanation by visiting http://wiki.secondlife.com/wiki/Key.

Q: So what happens when pinging stops?

A: When pinging stops, the data for that jar on the server side will begin to age. During this time, no new tip data is collected. And if no pinging is seen for 365 days, the data is erased. So it is important that all TipTracer users keep the following points in mind:

  1. The TipTracer system only holds on to data for jars that are pinging the server. Anytime you or your operators click the jar to bring up the options dialog, the jar pings the server. Also, anytime someone tips into the jar, the server is pinged. As a safety measure, even if the jar isn't interacted with for an extended period, it pings the server every 12 hours. So with all that pinging going on, the TipTracer system is always aware of all your registered MHS Donation Jars.

  2. The server will automatically unregister a jar, and delete all underlying tip data associated with it, if a ping hasn't occurred for 1 year (365 days). Such a condition arises if a registered jar has undergone a reset and you forgot to re-register it with the TipTracer system. Any of the following situations induces a jar reset:

    • You took the jar into your inventory, and then re-rezzed it.
    • You've updated the jar.
    • You've selected to reset the jar for any number of reasons, most likely to reload the notecards.
    • You got bored of Second Life and moved on to other things in life (shame on you!)

    To re-sync your jar back with your TipTracer tip history, you'll need to re-register the jar within the 1-year grace period.

  3. The TipTracer system keeps track of a jar's unique object key (also referred to as a "UUID"). If you take a jar into your inventory and then re-rez it, the jar will now have a completely different UUID. So after re-registering with the TipTracer system, it will be pinging the server under it's new UUID identity. From the server's perspective, it's an entirely different jar. How this effects you depends on whether you have the Copyable or No-Copy version of the MHS Donation Jar:

    Owners of
    Copyable
    Version
    Copyable tip jars that are re-rezzed from inventory have an entirely new UUID. This means that without any pinging from the original UUID, the server will eventually unregister it and delete it's older tip history after 365 days have passed. Directions below show how to re-link the data with the re-rezzed jar.
    Owners of
    No-Copy
    Version
    No-Copy jars have a recovery mechanism when they are re-rezzed with a new UUID, and it makes use of the jar's "Description" field. Whenever a No-Copy jar is registered with TipTracer, the Description field will be filled with text that looks like the following: "TipTracer [xxxxx]" (where xxxxx is some value). In contrast to an object's UUID, the description field remains intact after the jar is re-rezzed. When registering the jar with TipTracer, the description field is also sent to the server. When confronted with an unknown UUID, the server is then able to re-sync the existing TipTracer history with the new UUID.

    Copyable tip jars do not have this mechanism, otherwise numerous jars could be rezzed with that same description. That would render discrepancies in your tip history data.

So to summarize, it's entirely possible for the TipTracer system to delete an entire history of tip information when:

If your jar is... And you did this... Then your resolution is...
Copy
or
No-Copy
You ran the jar's Reset function, perhaps because you changed something in a configuration notecard and need it to be reloaded. Resetting a jar disables TipTracer. Re-Register the jar with TipTracer before the 1-year grace period expires. If a jar hasn't pinged the TipTracer system within that time, it's history is deleted.
No-Copy You have used the Updater Object to upgrade your jar to the latest version. (click here for updater info).

Whether you update your jar or re-rez it from your inventory, either of those actions will reset your jar which, in turn, disables TipTracer registration.

Re-Register the jar with TipTracer before the 1 year grace period expires. If a jar hasn't pinged the TipTracer system within that time, all of it's history is deleted.

You took a jar into inventory and then re-rezzed it, perhaps to move it to a new location.

Copyable

You took a jar into inventory and then re-rezzed it, perhaps to move it to a new location.

The jar is now inworld with a different UUID. From TipTracer's perspective, it's viewed as an entirely different jar. Here's what to do:

  1. Although not necessary, as an aid I recommend you rename your jar to distinguish it from it's prior existence. What's that mean? Well, if your jar is named "Joe's Tip Jar", then that's what the TipTracer system has it listed as. But now your jar has been re-rezzed with a new UUID. So rename* it to something like "Joe's Tip Jar -New".

  2. Re-Register the jar with TipTracer. At this point, TipTracer has two jars in it's system: "Joe's Tip Jar" and "Joe's Tip Jar -New".

  3. You will then need to use the Import utility to move all data from the original "Joe's Tip Jar" to it's newer incarnation now named "Joe's Tip Jar -New". Since the jars are named differently, you'll be able to easily distinguish them in the menu you'll see when clicking the Import button. (A picture of the import menu is shown in this page).

  4. After the history transfer, you can chop off "-New" from the jar's name. Then click the jar to bring up the options dialog. Doing that submits the jar's name to TipTracer, after which you can click Ignore to close the dialog.

    On the server side, there will now be two TipTracer entries named "Joe's Tip Jar", but the older one is no longer pinging the server (and, coincidentally, is now empty of historical data). For lack of pinging, TipTracer will eventually remove it.

You have received an update and you want to replace your older jar with the new one without losing all the historical data for the old jar.

This is a similar situation to what's described above. So here's what to do...

  1. Rename* your new jar from it's default name "MHS Donation Jar".

  2. (I always forget to do this myself!)... Prep your MHS Jar Config and MHS Operators notecards, then run Reset to load them.

  3. Now Register the new jar with TipTracer.

  4. Use the new jar's Import utility to move historical data from your old jar to your new jar.

  5. With no need for your old jar, you can simply delete it. There's no need to unregister your old jar. For lack of pinging, TipTracer will eventually remove it from the system.
* When I say "rename" above, I'm referring to the SecondLife method of renaming objects. Right-click the jar, select "Edit", and change the value in the "Name" field.
Home | Intro | Overview | Notecards | Updating | Sales | TipTracer | Login

ZappoWappy™ (c) 2006-2021