[geeklog-devel] Calendar Plugin - Recurring Events

[Anthony Rowles]

Randy, I think the issue is that if you're supporting complicated recurrence
rules, the calculation to "return the specific data you need" can be
resource-intensive and probably won't scale if it's done server-side.  Using
Joe's method, you only do this calculation once (when the event is saved),
while trading off with more space in your database (as you have to populate
events into the future).  With what I've proposed, you'd do this calculation
every time, but the calculation is done server-side so it scales, while
avoiding the space cost of populating lots of events into the future.  Joe's
method does have the advantage of making support for JS-disabled clients
much simpler, as well.

- Tony

On Thu, Apr 1, 2010 at 2:49 PM, Randy Kolenko <Randy.Kolenko at nextide.ca>wrote:

> Would this not be a perfect candidate for Ajax?
> Only request and return the specific data you need to parse the return
> feed on the client side and populate your calendar.  This way you're not
> returning 100,000 records, still doing client side parsing AND this
> still lets us have the routines written for javascript-crippled browsing
> clients.
>
> Likewise, if there are 50 birthdays on one day in a large organization,
> you're not going to show all 50.  You might show the fist 5 and then
> include a "more" link that can be ajax enabled that will show the next 5
> or 10 or whatever the setting is specified.
>
> Just a thought.  Ignore me if I'm being dumb.
>
> -randy
>
>
>
> > -----Original Message-----
> > From: Samuel Leathers [mailto:sam at theleathers.net]
> > Sent: Thursday, April 01, 2010 2:43 PM
> > To: Geeklog Development
> > Subject: Re: [geeklog-devel] Calendar Plugin - Recurring Events
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > One big question is how much should this be able to scale to? Lets say
> > the calendar contains 100,000 recurring events, of which, 10 are
> > actually recurring in the view period the user is looking at. If it's
> > parsed client side, you would have to send all 100,000 recurring
> events
> > to the client, so the client could determine if any are being shown.
> >
> > Whereas, if it's parsed/cached server side, you would only send those
> > 10
> > events, plus whatever non-recurring events happen for that time period
> > the user is viewing.
> >
> > That being said, this is an intriguing and interesting idea, granted
> > scaling is limited, and I hadn't even thought of having it parsed
> > client
> > side.
> >
> > Sam
> >
> >
> >
> > On 4/1/10 2:27 PM, Anthony Rowles wrote:
> > > If a user is downloading a calendar side block for the current
> month,
> > > and there's a 10 year old weekly meeting in the database, the user
> > would
> > > either need to download one copy of the recurring event or four
> > > instances of the event that have been populated into the database.
> > > Calculating the recurrence on the fly results in a page size
> > decrease.
> > >
> > > The problem I think you're talking about isn't really with long-
> > lasting
> > > events, but with infrequently recurring events.  There are
> definitely
> > > use cases where this could be a issue - for example, a calendar of
> > all
> > > employee birthdays for a large company.  A monthly-view side block
> > would
> > > have to receive every employee's birthday in order to check if any
> > occur
> > > during that month.  When I wrote some calendar software for a
> > government
> > > contractor that had to deal with a lot of quarterly and annual
> > reports -
> > > what I did was flag events with the months they could possibly occur
> > in,
> > > and use that as an additional filter.  This limits your recurrence
> > > possibilities somewhat ("every 42 days" would be impossible to
> > > implement, for example), but it's not a bad trade-off.
> > >
> > > - Tony
> > >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v2.0.13 (Darwin)
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> >
> > iQEcBAEBAgAGBQJLtOkbAAoJEF7J+Z7XDXx/8ZAIAIiphTYiXoPlOGsx0vNUG+Xa
> > VYQ8uQlmwRMyVUXXA+TMKEON9R1KaMh+ebBJKyXFReNarTBdj9E09FmJG+33rTm1
> > GDa4rIIf/bY0WOebFJ3XjPexsGbZGIWJxcWiJxU57Bk0opdG3bMP0qlgjFWqlTji
> > AxqHKNTmtCToBqGDEoHT8bzP2u6fgf1ZS7L/eK/Y+HgcPp+lX3y0EaGgfHN7C93Q
> > CPJyaINader39tsX3OrzxFw/b8ICA7ErOu4izc1+UKjB9XYgHWCVuXcZc5CLjYe6
> > nGR71rq8/0frM916h9RnHmXN0vHXEKCtwC7wuIe/a2S/bm+6Je7SYXeGTYSVgJo=
> > =Qn9q
> > -----END PGP SIGNATURE-----
> > _______________________________________________
> > geeklog-devel mailing list
> > geeklog-devel at lists.geeklog.net
> > http://eight.pairlist.net/mailman/listinfo/geeklog-devel
>
>
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://eight.pairlist.net/mailman/listinfo/geeklog-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist8.pair.net/pipermail/geeklog-devel/attachments/20100401/9d97bd94/attachment.html>