Aside from programatic license authentication, Dali provides a very limited number of services to normal users.
The Daylight 4.71 license manager has been modified to take advantage of Dali services. The license policy allows three license information sources which are specified by environment variables:
This is the first to be checked and is intended to be a dali service on the local area network, e.g., "hostname:dali". The timeout is typically set short, default is 500 (TOMS = timeout in milliseconds, so 500 = 1/2 second).
If DY_DALI_SERVICE is undefined or the request fails, the DY_LICENSEDATA file is checked. This functions identically to pre-4.71 behavior.
This specifies an additional network license server to be checked if the first two information sources fail. The intention is to make this a fallover which is accessed via proxy, e.g., "www.daylight.com:dali" and to set the timeout fairly long (default is 5000 or 5 sec.)
Same-old-same-old: don't define network services, don't run daliserver, put a license file on each machine and define DY_LICENSEDATA.
Operate a local license service, name it in DY_DALI_SERVICE, and centralize license management.
Do both of the above. If dali service fails for some reason, the software will fall back to local license file. Recommended for servers (at least initially).
Run daliservers on two machines on your LAN, name one as the primary service and the other as the authority service. This provides local fallover redundancy in case of hardware (but not network) failure. This strategy might be sensible for global licensees.
Operate a daliserver on your LAN, define both local and authority services. If the authority service is set to "www.daylight.com:dali", your Daylight software will always run even if your local service fails for some reason. Recommended for all installations with HTTP proxies.
Define the authority service as "www.daylight.com:dali" and do nothing else. All license requests will be handled by Daylight authority. Not recommended for general use, provides great benefits for demonstration purposes.
No longer need to install license files on each computer. Should be an improvement for corporate licensees.
Despite best efforts all around, not all license files get updated on all machines. Dali provides a solution in most such cases.
Demo and beta software can be shipped with the authority service set to daliserver at www.daylight.com. On systems with HTTP proxies, this software should run out "of the box" (out of the tar) without the inconvenient licensing step.
Daliserver can handle multiple licenses for a given CPU; authorization is given if it occurs in any license. We no longer have to replace licenses in toto, which should be convenient all around.
Pervasive computing is becoming a reality. As time goes on, it's becoming less sensible to license software on a per-CPU basis and more sensible to do so on a per-network basis. Dali will allow us to move to network licenses, e.g.,
The initial implementation of Dali allows clients to get license information from daliserver(s) in a network transaction. It's a short step to allow daliservers to access each other, i.e., periodically (or on any authorization failure?) check an authority source for an updated licenses. This might eliminate the requirement for customers to deal with license files at all.