[geeklog-devel] Hello Hello!

Thu Apr 1 17:41:42 EDT 2010

Hello everyone. Agana Agana-Nsiire, Ghana. I am looking into the
source code to see what it's like in geeklog.
so far, i'm liking the calendar project, but i am also considering a
few others. no time, so I should be decided soon. maybe a new idea.
I have never even heard of GSOC before this year, so this should be interesting.

I study zoology and conservation science in college, have never taken
any programming courses; really, up till now, i code just for fun
(since 2006), but i have a lot of growing still to do. I see this as a
golden chance to do that. this is important to me as i would like to
explore computing solutions for zoological and environmental research
in Ghana. Hopefully build my career around that. On my mind now, for
example, is an electronic field guide for birds that will run on
mobiles, so birders like myself can get a positive ID in seconds.
Currently the page flipping can cost valuable sightings! Maybe I'll
call it 'Wings'.

I love php, vb.net. learning python.
I love tennis, soccer, old books, birding (you should try it in Ghana).
I will soon submit my proposal, but for now just saying Hi.

Regards, Agana.

On 4/1/10, geeklog-devel-request at lists.geeklog.net
<geeklog-devel-request at lists.geeklog.net> wrote:
> Send geeklog-devel mailing list submissions to
> 	geeklog-devel at lists.geeklog.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://eight.pairlist.net/mailman/listinfo/geeklog-devel
> or, via email, send a message with subject or body 'help' to
> 	geeklog-devel-request at lists.geeklog.net
>
> You can reach the person managing the list at
> 	geeklog-devel-owner at lists.geeklog.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of geeklog-devel digest..."
>
>
> Today's Topics:
>
>    1. Re: Calendar Plugin - Recurring Events (Anthony Rowles)
>    2. Re: Calendar Plugin - Recurring Events (Samuel Leathers)
>    3. Re: Calendar Plugin - Recurring Events (Joe Mucchiello)
>    4. Re: Calendar Plugin - Recurring Events (Joe Mucchiello)
>    5. Re: Calendar Plugin - Recurring Events (Randy Kolenko)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 1 Apr 2010 14:27:33 -0400
> From: Anthony Rowles <aqrowles at gmail.com>
> Subject: Re: [geeklog-devel] Calendar Plugin - Recurring Events
> To: Geeklog Development <geeklog-devel at lists.geeklog.net>
> Message-ID:
> 	<u2i7e64bec31004011127o99e691e1s7fc0e91c1a52cb39 at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> 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
>
> On Thu, Apr 1, 2010 at 1:52 PM, Joe Mucchiello <joe at throwingdice.com> wrote:
>
>> At 01:15 PM 4/1/2010, Vincent Furia wrote:
>>
>>> Content-Type: multipart/alternative;
>>> boundary=0016e6db2b0a6fce690483300366
>>> Content-Transfer-Encoding:
>>>
>>>
>>> Tony,
>>>
>>> I like the idea of having the client do the work. But what happens if the
>>> client has JavaScript disabled? Will they be unable to view recurring
>>> events?
>>>
>>> -Vinny
>>>
>>
>> The problem with this is long lasting events and the calendar side block.
>> If a recurring event is weekly on Fridays and is create January 2001, will
>> that event have to be sent to the browser for every page hit if the
>> calendar
>> side block is visible? How do you filter events so you aren't sending
>> every
>> recurring event in the database to the client? (Looking at one of my yahoo
>> groups, there is a weekly event that was created in 2004 that we still
>> receive event notices for so don't think 10 year old events are
>> impossible.)
>>
>>
>> ----
>> Joe Mucchiello
>> Throwing Dice Games
>> http://www.throwingdice.com
>>
>>
>> No virus found in this outgoing message
>> Checked by PC Tools AntiVirus (6.0.0.19 - 10.004.172).
>> http://www.pctools.com/free-antivirus/
>> _______________________________________________
>> 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:
> <http://eight.pairlist.net/pipermail/geeklog-devel/attachments/20100401/e21acf71/attachment.html>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 01 Apr 2010 14:42:35 -0400
> From: Samuel Leathers <sam at theleathers.net>
> Subject: Re: [geeklog-devel] Calendar Plugin - Recurring Events
> To: Geeklog Development <geeklog-devel at lists.geeklog.net>
> Message-ID: <4BB4E91B.3080605 at theleathers.net>
> Content-Type: text/plain; charset=ISO-8859-1
>
> -----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-----
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 01 Apr 2010 14:57:22 -0400
> From: Joe Mucchiello <joe at ThrowingDice.com>
> Subject: Re: [geeklog-devel] Calendar Plugin - Recurring Events
> To: Geeklog Development <geeklog-devel at lists.geeklog.net>
> Message-ID: <0L070025WONN1XN0 at mta5.srv.hcvlny.cv.net>
> Content-Type: text/plain; charset=us-ascii; format=flowed
>
> At 02:27 PM 4/1/2010, Anthony Rowles wrote:
>>Content-Type: multipart/alternative; boundary=0016e64cd4fa0e32b00483310549
>>Content-Transfer-Encoding:
>>
>>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.
>
> This is why if you precalculate it all once (when the item is saved)
> then all access to a set of events is not only faster but the code is
> SIMPLE to maintain. The every 42 days event works just fine if it is
> pre-calculated once. Then any time someone selects a range of events
> (May 2011 for example) if there is an event in that month that
> matches the calculation cost during the select is just one more row
> as opposed to a lot of date manipulation.
>
> A complex morass of exceptions that has to run on both the client and
> on the server is not something the core devs should have to deal with
> 4 years from now when perhaps you have moved on. If all the code is
> in one place and only ever has to run while the user creating the
> event is saving the event, it makes the code easier to maintain going
> forward. I think the agile programming folks call this the DRY
> princicple: Don't Repeat Yourself.
>
>
> ----
> Joe Mucchiello
> Throwing Dice Games
> http://www.throwingdice.com
>
>
>
> No virus found in this outgoing message
> Checked by PC Tools AntiVirus (6.0.0.19 - 10.004.172).
> http://www.pctools.com/free-antivirus/
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 01 Apr 2010 15:03:21 -0400
> From: Joe Mucchiello <joe at ThrowingDice.com>
> Subject: Re: [geeklog-devel] Calendar Plugin - Recurring Events
> To: Geeklog Development <geeklog-devel at lists.geeklog.net>
> Message-ID: <0L07008DEOXMG0D0 at mta3.srv.hcvlny.cv.net>
> Content-Type: text/plain; charset=us-ascii; format=flowed
>
> At 01:03 PM 4/1/2010, Vincent Furia wrote:
>>Be careful depending on the iCal standard to define how recursion
>>works in your implementation. The iCal recursion rules are VERY
>>flexible and fully implementing them can be crazy difficult (not
>>even Outlook can generate all the types of recursions that are
>>supported by iCal).
>
> The value of attempting to code to the iCal standard is you don't
> have to implement it completely. You only have to implement as much
> as your GUI can handle. Besides probably 20% of the standard handles
> 80% of the common use cases. So you can start out with a subset of
> the iCal standard that does what is minimally necessary (as well as
> possible in the GSoC timeframe) and have another/more project(s) to
> handle more of the standard at a future date. This is the place for
> lots of Javascript in the recurring code: as part of the GUI to
> handle all the types of recurring events. For the calendar display,
> it is better to handle it with AJAX and perhaps some fetch ahead if
> you want to be fancy.
>
>
> ----
> Joe Mucchiello
> Throwing Dice Games
> http://www.throwingdice.com
>
>
>
> No virus found in this outgoing message
> Checked by PC Tools AntiVirus (6.0.0.19 - 10.004.172).
> http://www.pctools.com/free-antivirus/
>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 1 Apr 2010 14:49:36 -0400
> From: "Randy Kolenko" <Randy.Kolenko at nextide.ca>
> Subject: Re: [geeklog-devel] Calendar Plugin - Recurring Events
> To: "Geeklog Development" <geeklog-devel at lists.geeklog.net>
> Message-ID:
> 	<063B8B70CB9DA141B2FC1DB483561B9F3834BC at nex-pluto.nextide.ca>
> Content-Type: text/plain;	charset="us-ascii"
>
> 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
>
>
> End of geeklog-devel Digest, Vol 40, Issue 4
> ********************************************
>