NYCPHP Meetup

[csnyder]

On 3/29/06, inforequest <1j0lkq002 at sneakemail.com> wrote:

[skipping math -- we're engineers here]

> So what gets stored (and queried)? Well... seems unlikely we want to do
> linear algebra on a web server for potentially every HTTP request, so we
> need temp tables of "event date".

Presume you mean event data.

> How often must they be regenerated?
> How far out into the future do we need to have handy, or at what cost do
> we ask the smarter server to regenerate them? How often will it be
> updated, and how far into the future?

Well now you're cheating. ;-)

Or rather, you're making a practical case for pre-rendering all of
those time slices so that when you go to render a calendar view
(whether 1 month or 3 days or 2 hours) you can just fetch all of the
slices that apply and spit them out in a template.

> At first
> looking back is clumsy as it can be huge... but then history won't
> change so those are archives anyway.

Yes, exactly. You just never update timeslices that apply to times in the past.

I'm not sure how much longer this needs to carry on, but I'll go back
to my original post and point out that there is some benefit to just
brute-force plotting recurring events as they are inserted / updated.
There's around 500,000 10-minute time slices between now and 2016.
It's a big number, but not scary big. Any single recurring event is
going to touch a miniscule fraction of them.

So your "temp" table could actually reflect changes in real time.

And lets not forget that people and resources can be mapped to
timeslices as well, which gives you scheduling capability.

But the real question is... who besides Jeff Knight is crazy enough to
build such a system?
If you get it right, you'll be well on your way to replacing
everybody's most-hated email server....