Revoking

Well, there are many ways to do this. The short answer is we'll be making this easy in TurboActivate 3.3. You'll be able to pass in how often you'd like to check and let TurboActivate handle the details.

How do you recommend storing the 'date last checked' so that user cannot simply keep resetting this local date to continue use?

There are a few different ways. Cryptographcally signing the last check date is one option.

Ok so got to ask.....what's the 3.3 timescale?

Days, weeks or months?

Weeks. 2 to 3. We're working to get this out ASAP.

Afternoon Wyatt,

This sounds great - facing this conundrum right now.

So; lets say we set it to check every 7 days; can we also set a "number of failures" i.e. up to 2 or 3 times not getting an internet connection? And return values, properties or events (like the auto-updater) so we can warn user?

(So we can say "last checked n days ago, n more attempts before application will automatically deactivate?" or something like that).

So if we have 3 times set and 7 days then we'd know 21 days maximum before deactivation?

Bit cheeky question: do you need beta testers for this? As we're trialling the functionality now it'd be great to be able to do this fully.

Thanks, Michael Dye.

So; lets say we set it to check every 7 days; can we also set a "number of failures" i.e. up to 2 or 3 times not getting an internet connection? And return values, properties or events (like the auto-updater) so we can warn user?

You can specify how often to check and how long the grace period should be if when TurboActivate checks it runs into a problem (that is, it can't connect to LimeLM servers). Prior to 3.3 you'd have to handle this all yourself. With 3.3 we're wrapping it all into a single function call that handles all the details.

Bit cheeky question: do you need beta testers for this? As we're trialling the functionality now it'd be great to be able to do this fully.

It's not quite ready yet. We're pushing it out the door soon, but we don't want to have a version out there that's broken.

Thanks Wyatt,

No probs - quick question - will we be able to read the "last successful date" plus the fact that a check has failed (and so in the grace period)?

{Just like to add this techi sort of info to our help/debug output so a user can read it back to us if required - we do the same with auto-update}

Ta, Michael.