Development testing: three features needed for enterprise us

1) Possibility to change where the license is being stored

Storing in the common profile is coming with TurboActivate 3.0 (in about 2 weeks).

3) Static library

Also coming with 3.0.

2) Easy possibility to manage more "versions" with just one TurboActivate.dat

We recommend using a single TurboActivate.dat for your main program and license features for your individual modules. Does this work for you?

No unluckily it is not working for me cause the module in future will be inserted from our customers from a website and this should make them able to sell to their customer. That wont be a feature of the product. Just an external module.

See it like a dll that when run from our exe will use the activation system to check if it is enabled or not.

Another feature that i would like is the ability to load the testactivate.dat from a stream

No unluckily it is not working for me cause the module in future will be inserted from our customers from a website and this should make them able to sell to their customer. That wont be a feature of the product. Just an external module.

I'm afraid I don't quite understand. Will you customers be generating product keys for their modules? Do they sell these modules through your website?

Here's how I see it working -- tell me if I'm off the mark. You generate a product key for your main product and give it to an end-user. The end-user enters this product key and activates your app. Then, they decide to buy ModuleX from one of your partners. They purchase ModuleX from your website and you enable the ModuleX feature for the product key and give them a link to download it.

In other words, ModuleX is now enabled and can be used with your app.

Is this what you're trying to accomplish, or have I gotten wrong?

No unluckily it is not working for me cause the module in future will be inserted from our customers from a website and this should make them able to sell to their customer. That wont be a feature of the product. Just an external module.

I'm afraid I don't quite understand. Will you customers be generating product keys for their modules? Do they sell these modules through your website?

Here's how I see it working -- tell me if I'm off the mark. You generate a product key for your main product and give it to an end-user. The end-user enters this product key and activates your app. Then, they decide to buy ModuleX from one of your partners. They purchase ModuleX from your website and you enable the ModuleX feature for the product key and give them a link to download it.

In other words, ModuleX is now enabled and can be used with your app.

Is this what you're trying to accomplish, of have I gotten wrong?

Yes. But ModuleX is not developed by us. It has been developed by a third party and inserted in a store without our manual intervention.

So in other words it is meaning that the web backend has been able to add a new feature to all the versions of the product OR it has been able to add a "version" specific for that modulex inside the product.

Right now i experimented adding a generic feature module_id# with a list of module_ids separated by comma as value. Obviously i don't know how many features i can add to a version and how many characters a string feature can keep inside. The downside is the maintain of this list of module_ids.

The solution that i have in mind is to be able to add with the webapi a version to a product that it will be specific for that moduleX and my partners will be able to generate code keys specific for that version.

Right now i experimented adding a generic feature module_id# with a list of module_ids separated by comma as value. Obviously i don't know how many features i can add to a version and how many characters a string feature can keep inside. The downside is the maintain of this list of module_ids.

There's a 2 gigabyte limit (so, for all practical purposes, unlimited). But you're right, iterating through a list of module ids is a hassle.

The solution that i have in mind is to be able to add with the webapi a version to a product that it will be specific for that moduleX and my partners will be able to generate code keys specific for that version.

I think creating a separate version for each module is overkill. What if we added the ability to create a license feature using the LimeLM web API? For instance, here are a few workflows I imagine:

Partner adding a new module

When one of your partners offers a new module for sale they can use your website (or contact you some other way) and you can automatically add a feature for that module. Let's say CompanyX creates ModuleX and wants to offer it up for sale. They go to your website and add the ModuleX details. Your servers contact LimeLM using the web API to generate a new license feature named "ModuleX".

Selling ModuleX

When you (or your partners) sell ModuleX to the end-user you won't need to generate a new product key for ModuleX. Instead you can just prompt for the end-user's product key to your app. Then using the limelm.pkey.setDetails web API you can set the "ModuleX" feature value to something like "enabled".

Using ModuleX in your app

The customer has purchased ModuleX, they've downloaded and installed it. You can re-download the latest feature data for the customer by calling Activate() again. For instance, you could call this after a new module is added to your app.

Then, to see if ModuleX is actually licensed, you call TurboActivate.GetFeatureValue("ModuleX") within your app. And you can enable/disable the module based on the value.

----

Does this workflow work for you? If so we can add the ability to add/remove new "license features" using the web API.

If you would add that possibility to add a feature trough the web api, it would be wonderful.

The other, is it possible too? To read the TurboActivate.dat from a stream? And if it would be for me, i would add the possibility to TurboActivate.exe also to read the TurboActivate.dat from pipe (or at least release the sources of it to be able to modify it, if possible). Like this virtually i would be able to include the TurboActivate.dat inside the application resources (as many as i want). This is needed because right now we have different products that are installed in the same folder but requires different activations and we would like to don't change the structure of the installation to accomodate the needs of the new activation system.

EDIT: I noticed a problem about Trials.There is no way to learn if i executed once the UseTrial functions and TrialDaysRemaining is always returning the maximum if i never executed UseTrial. Also, until i activate GracePeriodDaysRemaining is counting down trough 0 but i never "inserted" a product key. So must i suppose i am always in graceperiod or not?

EDIT2: I would like to be able to extend a trial trough turboactivate.exe too.

If you would add that possibility to add a feature trough the web api, it would be wonderful.

Sure, we'll get to work on it right away.

This is needed because right now we have different products that are installed in the same folder but requires different activations and we would like to don't change the structure of the installation to accomodate the needs of the new activation system.

Using the TurboActivate API you can use the PDetsFromPath() function to load it from a file other than TurboActivate.dat. If we added that ability to TurboActivate.exe (e.g. a commandline switch like -pdets="C:\Your Path\ta.dat") would that work for you?

This way you can have multiple *.dat files in the same directory and you can call them whatever you want.

The reason we're wary about adding the ability to load from streams is that this significantly increases complexity on the various platforms and languages using TA (C#, Java, etc.). We might implement this "load from stream" feature in the future, but for now would multiple files on disk work for you?

There is no way to learn if i executed once the UseTrial functions and TrialDaysRemaining is always returning the maximum if i never executed UseTrial.

If you're in "trial mode" you should always execute UseTrial() before calling TrialDaysRemaining().

Also, until i activate GracePeriodDaysRemaining is counting down trough 0 but i never "inserted" a product key. So must i suppose i am always in graceperiod or not?

That's correct, the grace period is started the first time GracePeriodDaysRemaining() is called.

EDIT2: I would like to be able to extend a trial trough turboactivate.exe too.

So you would like the TurboActivate wizard (TurboActivate.exe) to use trials instead of the "grace period" and you would like the ability to extend the trial when it runs out?

This is needed because right now we have different products that are installed in the same folder but requires different activations and we would like to don't change the structure of the installation to accomodate the needs of the new activation system.

Using the TurboActivate API you can use the PDetsFromPath() function to load it from a file other than TurboActivate.dat. If we added that ability to TurboActivate.exe (e.g. a commandline switch like -pdets="C:\Your Path\ta.dat") would that work for you?

This way you can have multiple *.dat files in the same directory and you can call them whatever you want.

This would work for now, sure.

The reason we're wary about adding the ability to load from streams is that this significantly increases complexity on the various platforms and languages using TA (C#, Java, etc.). We might implement this "load from stream" feature in the future, but for now would multiple files on disk work for you?

Yes, i thought it focused on Windows, but yes, you are right it would be difficult. But i'm still of the idea that it would be helpful.

There is no way to learn if i executed once the UseTrial functions and TrialDaysRemaining is always returning the maximum if i never executed UseTrial.

If you're in "trial mode" you should always execute UseTrial() before calling TrialDaysRemaining().

Yes but how can i know if i am in "trial mode"? I would like to have a function to be able to know if the user ever started a trial or also if the user ever inserted a product key.

EDIT2: I would like to be able to extend a trial trough turboactivate.exe too.

So you would like the TurboActivate wizard (TurboActivate.exe) to use trials instead of the "grace period" and you would like the ability to extend the trial when it runs out?

Yes i would like to be able to use turboactivate to start a trial and to extend it without needing to implement my own UI. Just to be consistent along the program, if it is possible.

P.S. why quotes are not working for me?

Yes but how can i know if i am in "trial mode"? I would like to have a function to be able to know if the user ever started a trial or also if the user ever inserted a product key.

That's up for you to decide. We look at it this way: if the user is not activated then they are in trial mode (even if they have a product key entered). If the user is activated then they are not in trial mode.

Does this make sense?

Yes i would like to be able to use turboactivate to start a trial and to extend it without needing to implement my own UI. Just to be consistent along the program, if it is possible.

Ok, we'll squeeze this in for the TurboActivate 3.0 release.

P.S. why quotes are not working for me?

Sorry, we had to disable BBCodes for all users (except admins) because of the spam problem. Bots were registering to this site and posting porn and other obscene things. Unfortunately our forum software doesn't allow enabling only certain types of BBCodes -- it's an all or nothing sort of thing.

Short answer: once we switch to our in-house developed forum software this will be all fixed. In the meantime it will all look ugly.

Yes but how can i know if i am in "trial mode"? I would like to have a function to be able to know if the user ever started a trial or also if the user ever inserted a product key.

That's up for you to decide. We look at it this way: if the user is not activated then they are in trial mode (even if they have a product key entered). If the user is activated then they are not in trial mode.

Does this make sense?

Mmmmh. Not quite.

In fact after thinking how the system is working i noticed that if i delete the four positions where the license is stored (and the trial too) the application began the trial from the begin again. If i will repeat this operation everyday everyday i will have a trial period (EDIT) forever.

It would be better to have a server side trial like a normal license in fact. Is this possible?

If i set the trial days to 0 and then use the online extension methods to extend the trial to the desired value is it possible to avoid the described behaviour?

Mmmmh. Not quite.

If you're using the trial behavior of TurboActivate (i.e. using UseTrial, TrialDaysRemaining, ExtendTrial) then detecting whether the customer is in trial mode or not is simply at matter of detecting if they are activated (i.e. calling the IsActivated() function).

In other words, if they're activated it means they have a valid product key (and thus not using your trial any more).

Does this clarify things?

[...] If i will repeat this operation everyday everyday i will have a trial period (EDIT) forever.

That's the problem with unverified trials -- they don't need to be confirmed with a 3rd party and the trial data is eventually stored somewhere on disk.

But you already know that, which brings us to the two possible verified trial options...

Server verified trials, option 1

If i set the trial days to 0 and then use the online extension methods to extend the trial to the desired value is it possible to avoid the described behaviour?

Yes, that's possible. This way the trial key (a.k.a. the trial extension) can be only used a limited number of times. and if they delete the trial data from the computer then their trial is reset to 0.

Server verified trials, option 2

It would be better to have a server side trial like a normal license in fact. Is this possible?

Sure, this is also possible, but it's a bit more complicated -- it's better if you use the other option.

But if you want to go down this route then the first thing you'd have to do is create a license feature like "trial_expires" as a "Date / Time" feature and uncheck the "Required" checkbox.

Then, the difference between a "trial license" and a "regular license" becomes whether the "trial_expires" feature is set or not. For instance, to create a "trial license" then set this "trial_expires" feature with a date in the future (e.g. 2011-12-25). Then when the customer activates the product key the "trial_expires" features is downloaded.

Detecting whether the activation is a "trial" would be simply a matter of calling "GetFeatureValue("trial_expires", ...)". If the feature is present then the customer is in "trial mode" and you simply use the date to decide whether to keep allowing your potential customer to keep using your app or not.

If this potential customer becomes a paying customer then you have 1 of 2 choices.

1. You can deactivate their trial license and let them use another product key you send them.
2. Or, you can remove the "trial_expires" feature data from their existing product key and your app can call the Activate() function to download the new feature data.

Obviously the "Server verified trials, option 1" is the easier choice.

Does this make sense?

We've just added the ability to add, remove, and edit license features using the LimeLM web API. We'll update the LimeLM web API pack with the easy to use functions a little later today.

• limelm.feature.add
• limelm.feature.delete
• limelm.feature.edit

Ok this all makes sense.

I think in the next months we will be for sure a new customer as soon as the other features will be implemented (like management of trial and extension directly from turboactivate and the possibility to point turboactivate to other dat or the common path for the license).

Great, we'll keep you up-to-date on our progress.

TurboActivate 3.0 is out. We've added all features you've asked for.

• Static library version of TurboActivate.
• System-level activations.
• Trial extension in the TurboActivate wizard (there's a screen shot of this on the trials help page).
• The ability to specify different product details files to TurboActivate using the --pdets commandline switch.

Hello,right now i'm again testing LimeLM because we are going to introduce it in our software. BTW, thanks for all the modifications that will help me to use it.

I have some doubts:

1) If i use trialextensions must i use UseTrial function?2) Why TrialDaysRemaining is returning one day less? Like that if i have 1 day of trial and i check the function it is returning 0, and tomorrow will return 0 again. But in fact today should say 1, because i have 1 day of trial.3) How can i "deactivate" a trial extension?4) If i want to extend a trial before the trial effectively ends how can I?

4) If i want to extend a trial before the trial effectively ends how can I?

You mean from within the TurboActivate wizard? There's really no way. If you mean with the code, then simply call ExtendTrail().

3) How can i "deactivate" a trial extension?

I'm not sure what you mean by that -- can you explain what you're trying to do?

2) Why TrialDaysRemaining is returning one day less? Like that if i have 1 day of trial and i check the function it is returning 0, and tomorrow will return 0 again. But in fact today should say 1, because i have 1 day of trial.

That's a bug -- we'll fix it for TurboActivate 3.1 (coming monday) or TurboActivate 3.2 (coming in a couple of weeks).

1) If i use trialextensions must i use UseTrial function?

Yes, before you make use of the TrialDaysRemaining() function you must call the UseTrial() function. You can call the UseTrial() as many times as you want -- it doesn't reset the trial. It just sets the trial up the first time it's called.

3) How can i "deactivate" a trial extension?

I'm not sure what you mean by that -- can you explain what you're trying to do?

I would like to delete all the trial data from the account or the machine.

You can remove activations & product keys using the Deactivate() function in TurboActivate. However, the only way to "reset" a trial is to use trial extensions.

Ok this is fine for me, i can include an offline trial with the executable and run it before executing the online or offline activation of a full license.

Apart this, during our further investigations we noticed that in TurboActivate there are two links "What is activation?" and "Read the privacy statement online" that are pointing to LimeLM web server. We would like to be able to change these two links making them point to our servers instead of your. This is quite important. In my opinion it can be done in the same way as a normal traslation.

OK -- we'll add the ability to specify those links in your translation for TurboActivate 3.1 (coming out soon).

Thank you really much.

BTW, my support and sales team is suggesting me that they would like the following functions of the web api to work for the trial extensions too.

limelm.pkey.activitylimelm.pkey.advancedSearchlimelm.pkey.deletelimelm.pkey.findlimelm.pkey.getDetailslimelm.pkey.getID

They are seeing they would be helpful to measure the activity on the trial side.

OK, we'll work on those too.

We've finished support for customizing the "What is activation?" and "Read the privacy statement online" links in the TurboActivate wizard. Use TurboActivate 3.1 (or above) and edit your translation to use your own links.

Thank you really much.

BTW, my support and sales team is suggesting me that they would like the following functions of the web api to work for the trial extensions too.

limelm.pkey.activitylimelm.pkey.advancedSearchlimelm.pkey.deletelimelm.pkey.findlimelm.pkey.getDetailslimelm.pkey.getID

They are seeing they would be helpful to measure the activity on the trial side.

Wyatt, do you have a time frame for these functions? One month passed and my marketing and support team is beginning again to ask about them.

We plan to have several of the trial extension web API function done by the middle of this week. (Wednesday/Thursday).

Just an update: we'll have a few of the new trial extension web API function out Friday afternoon.

Did you post them somewhere? I didn't see where if they are posted...

Sorry, we had to delay the release a little bit for some last minute bug fixes. It will be out later today.

We've just released 2 of the new trial extensions:

• limelm.trialExtension.delete
• limelm.trialExtension.search

Hi wyatt,I was hoping that with the release of the version 3.2 of TA also the other requested functions for the trial would be released too.

limelm.pkey.activitylimelm.pkey.findlimelm.pkey.getDetailslimelm.pkey.getID

These would be interesting, mostly the second last getDetails.

Can you give me a feedback?

Thank you,Tommaso

Sure, we can add those.