andrel <a_l### [at] hotmailcom> wrote:
> Trevor G Quayle wrote:
> > Fa3ien <fab### [at] yourshoesskynetbe> wrote:
> >> Since POV-Ray (for Windows, at least, I don't know about other systems)
> >> is already able to access the internet to give some feedback or check
> >> for updates, why not :
> >> - set an expiration date in the binary
> >> - once the expiration date is over, if there is no new beta,
> >>    POV-Ray can get some kind of "certificate" which allows it
> >>    to continue working as long as the Team wishes.
> >>
> >> (of course, this has problems like "not every machine running
> >>   POV-Ray has internet access", etc.. but it might be a nice
> >>   solution for most people)
> >>
> >> It could also take the form of some "licence file".
> >>
> >> Fabien.
> >
> > Or built-in unlock codes that are only released by the team when necessary.
> > (beta expires with no new one available)
> >
> My suggestion still is to compile a few beta's with different expiry
> dates and release an extended beta when necessary. That costs a
> recompile but there is no change of the current code required.

However this would require downloading and installing the binary. Not that
that would generally be a problem, you need to do this if it were a new
beta anyways, however people are always averse to extra downloads.
I don't think an automatic checker would work either as that requires being
able to connect through a network and this isn't always possible for some
users due to set-up or permissions.
This is why I think built in unlock codes would work best.  Users are
already visiting the download page to get the new beta, so if the
applicable valid code is posted it's a simple matter of feeding it to POV
when it asks, no extra download required (still would need a capable net
connection, but this would only require browsing permissions).  Using this
could also eliminate the need for adding a click-through warning screen for
extended betas, which also seems to be undesirable.

-tgq

Post a reply to this message