winterize-users team mailing list archive

[Max Polk <maxpolk@xxxxxxxxx>]

I've been away helping webplatform.org with a conversion of JavaScript
reference information, and that effort reached a milestone, read about
it at:

    http://blog.webplatform.org/

Back to Winterize.  Note that the final name will be "Winter" and if
launchpad.net won't let me have a project with that name, I'll move to
github or somewhere else.  From now on, I'll call it by its true name
"Winter."

I've come up with some pretty solid architectural ideas about solving
the problem of resource mutual resource consistency.  By resource I
mean the value of an URL hosted by the Winter server, or any other URL
on the WWW.  A core feature of Winter is the ability for a resource to
be a function.  You can state that the value of a resource is a
function performed against the value of another resource.

So then if resource A is declared to be resource B + 1, and resource B
is declared to be resource A + 1, what would that even mean, and how
would you handle it?  A friend pointed out that what you are really
saying A(n) = B(n-1) + 1, and B(n) = A(n-1) + 1.  You declare that a
value is a function applied to the other resource's previous value.
If the other resource is an external value, you declare that a value
is a function applied to that external resource's previous value (a
point in time).

For this to work, calculations must progress in rounds.  Each round of
values depends on the previous round's values.  Progress through all
calculations as one "generation" and finish.  Then repeat.  While each
group of related resources can independently progress through
generations independently, perhaps for simplicity all resources
progress on the same generation.

So if A = B + 1, and B = A + 1, we have initial values to start it all
off, let's say, 0 and 0.  Then:

Generation 0:
    A=0, B=0 (fixed intiial values)
Generation 1:
    A=1, B=1
Generation 2:
    A=2, B=2

At no point can a resource assert its current generation's value is
equal to another resource's current generation's value.  The other
external resource is out of date possibly as soon as you obtain it's
value.  The other internal resource is out of date as soon as you
complete that generation.  A and B will progress, as fast as possible,
unending.  While this example is trivial and pointless, it will be
useful to declare A to be the next prime number, and B to be the last
calculated value.  Winter can then calculate prime numbers as fast as
possible forever.

One thing to remember is that resources on the WWW across domains are
impossible to be correct.  As soon as you obtain your bank account
value, it's out of date the moment your eyes see it in the web
browser.  Couple that with the fact that one can never obtain two
resources having mutually consistent values at the same time.  You can
only do an HTTP GET of one resource, then another HTTP GET of another
resource.

To save the day, Winter will always return the previous generation's
values for all resources while processing a new round of values.
Users obtaining A and then B during the round of processing of a new
generation of their values can obtain mutually consistent values for A
and B, risking the change that the round of processing completes after
obtaining A and before obtaining B.  So it may be worth being able to
ask for A, and with the response you have an http response header that
declares what generation number it represents.  Then you can request B
and ask for that same generation.  You then have mutually consistent
values of A and B even though http as a protocol won't let you obtain
both in one request.

While no code has been pumped out into the revision control system,
architecture is moving forward.