[geeklog-devel] Calendar Plugin - Recurring Events

[Randy Kolenko]

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