[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Part 2: System Structure

From: Marcus Brinkmann
Subject: Re: Part 2: System Structure
Date: Mon, 15 May 2006 02:07:57 +0200
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (Sanjō) APEL/10.6 Emacs/21.4 (i486-pc-linux-gnu) MULE/5.0 (SAKAKI)

At Sat, 13 May 2006 12:24:31 +0200,
Pierre THIERRY <address@hidden> wrote:
> [1  <multipart/signed (7bit)>]
> [1.1  <text/plain; us-ascii (quoted-printable)>]
> Scribit Bas Wijnen dies 13/05/2006 hora 08:59:
> > I do see one problem with this approach though.  If the game is a
> > service provided by some server, then the user doesn't pay for the
> > resources which are used by the game.
> Indeed. Without some ability to give resource usage along with request
> of using it, this won't work with games.

This is just because you are trying to do something that is very
complicated.  On the one hand, you want to run the competition on the
users resources, on the other hand, you want the competition to be
able to reliably update the high score file.  In these requirements
you are already presupposing DRM, plus opaque resource donation, plus
a non-confined "competition constructor" server, plus a careful
competition program design that runs some parts of the competition on
durable resources and some on non-durable resources.  All of this is
technically possible, but the complexity is inherent in the goal.

In Unix it just looks simpler because the resource accounting is sloppier.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]