Re: [PHPiCalendar-DEV] Re: code cleanup patch

[David F. <da...@d2...>]

it doesn't add new copies of the event (my current limited understanding 
is the master_array "renders" out the original event regardless of when 
it is, and then whatever events are around the date range you're looking 
at). All I'm doing is adding the $recur data to every copy of the event, 
whereas before it was just in the original event (making it impossible 
to look up the info unless you were looking at the original event). So, 
it really depends on how many recurring events you've got, in terms of 
what absolute amount of size it adds to master_array.

While I'm on the subject, you theoretically could drop $master_array a 
lot, by separating it out into two arrays - one $event_array that held 
all the events indexed by calendar/uid, and $master array that held the 
rendered-out events indexed by date/time as usual, but instead of 
holding the full event data, they'd just hold a "pointer", if you will, 
of the calendar/uid, so you could lookup the actual data in 
$event_array. Dunno about the specifics, but It'd vastly compress any 
recurring event info, which is where your space really grows since each 
recurring event that's "rendered" into master_array holds the full event 
text, organizers, attendees, etc. etc. It'd be even better/easier if you 
can assume $uid is unique across calendars, which (if it isn't already a 
safe assumption), you could have ical_parser guarantee as you were 
building the arrays. :) Not something I'm quite ready to tackle yet, but 
food for thought.

dave

Jim Hu wrote:
> I think we need Chad to weigh in before changing how the master array 
> handles repeating events...what happens to the size of the array if the 
> event is set to repeat forever?
> 
> Jim Hu
> 
> On May 3, 2005, at 7:47 PM, 
> php...@li... wrote:
> <snip>
> 
>> Message: 2
>> Date: Tue, 03 May 2005 16:29:54 -0700
>> From: David Fallon <da...@d2...>
>> To: php...@li...
>> CC: ji...@ta...
>> Subject: Re: [PHPiCalendar-DEV] code cleanup patch - more fixes
>> Reply-To: php...@li...
>>
>> This is a multi-part message in MIME format.
>> --------------080707090207070601060108
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>> Content-Transfer-Encoding: 7bit
>>
>> So, this is worth applying, but only if you don't apply my forthcoming
>> patch - I'll shortly (maybe later today) have a reworked
>> openevent/event.php setup that uses date+time+uid to lookup the event,
>> instead of passing the data to the page. This leads to a few questions:
>>
>> 1. is this acceptable? I'm kinda running wild here since no one's saying
>> anything, but obviously I'd like to run wild in the right direction.
>>
>> 2. if the patch goes in, it's significantly less data to pass through -
>> which means we could remove the "changing the hidden form" hackery? If
>> so, let me know, I'll put together a patch.
>>
>> 3. I noticed a two  issues with the generation of master_array - first,
>> the recur data wasn't being replicated to each instance of the event,
>> only the first event - so (without iterating through the whole array)
>> there was no good way to get it. So, I fixed that. This raises the size
>> of master_array by a decent amount, so it's questionable, but necessary
>> for me to implement recur details in the event popup. Second, all-day
>> recurring events after the first one weren't getting set with valid uids
>> - they were being added to the allday time w/ the "next" array key,
>> instead of using the uid. This is less questionable, and a one-line fix
>> - both fixes are in the patch, but if you want to cherry pick and would
>> prefer this fix alone, let me know.
>>
>> So everyone knows, my immediate goals are:
>>
>> * adding recur info to the event.php popup, so it's more useful, and so
>> I learn enough to do:
>>
>> * add basic event adding/editing. This obviously assumes that the
>> phpicalendar "owns" the calendar, and thus will ignore locking/sync'ing
>> beyond making sure it doesn't overwrite itself. This will be entirely
>> optional (I'm happy to make it some sort of config option people have to
>> turn on in general or per-calendar).
>>
>> * And then probably add a basic level of user support, so users can have
>> their own calendars vs. shared calendars, etc. Simplistic calendar 
>> server.
>>
>> As always, I'd much prefer to do this the "right" way, in that
>> maintaining a patch set against CVS sucks long term - so if there are
>> way you'd prefer this done, please let me know and spare me the time
>> reworking things later. phpicalendar has a *@(#ing awesome interface, by
>> far the best I've seen so far, and the last piece I need to solve a few
>> problems for me is the editing.
>>
>> (cc'd jim so you get the patch)
>>
>> dave
>> <snip>
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.
> Get your fingers limbered up and give it your best shot. 4 great events, 4
> opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
> win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
> _______________________________________________
> Phpicalendar-devel mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel
>