From tcsp1900 at hotmail.com Thu Apr 1 01:27:48 2010 From: tcsp1900 at hotmail.com (Tim Patrick) Date: Thu, 1 Apr 2010 01:27:48 -0400 Subject: [geeklog-devel] geeklog-devel Digest, Vol 39, Issue 53 In-Reply-To: References: Message-ID: Hey, I would like to have community feedback on an extended proposal I have created for the Cross Site Alert system. Please read the entire document and offer your throughts on the Interesting Concept section. http://docs.google.com/View?id=dgfc479g_36d58qw9hq - Tim _________________________________________________________________ IM on the go with Messenger on your phone http://go.microsoft.com/?linkid=9712960 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wilfer.sis at gmail.com Thu Apr 1 03:45:53 2010 From: wilfer.sis at gmail.com (William Garcia) Date: Thu, 1 Apr 2010 03:45:53 -0400 Subject: [geeklog-devel] Proposal idea In-Reply-To: <20100331195145.1241498431@smtp.haun-online.de> References: <991e66d91003220421n70742f2by2ff290ece4993d1f@mail.gmail.com> <20100322190158.1901950332@smtp.haun-online.de> <991e66d91003221503r42d80849t3cf2299a711315dd@mail.gmail.com> <20100323194819.255135035@smtp.haun-online.de> <991e66d91003232323l16452ebekaac1f6a701b76dff@mail.gmail.com> <991e66d91003291713k69f34991w7f7698c5d762275b@mail.gmail.com> <20100331195145.1241498431@smtp.haun-online.de> Message-ID: hi, To write the pluguin need not known modeling language, only to have basic knowledge of UML, If someone plan to upgrade the generator must have good knowledge of modeling with UML, the generator creates code in the templates, these are developed using Xpand [1] this language is really easy to have a few sentences (about 10), necessitating to develop other functions to perform more specific tasks, these must be developed with Java and this extensions are included in the generator, but I have developed these methods (I've needed so far). Knowledge transfer will be made during development of the generator, while I am assembling the generator I will document this process and to begin to build the generator from scratch anyone is interested in the generator will understand quickly. >From my experience I can contribute in the development of an excellent generator and provide support until the appearance of a method in which I am using obsolete. cheers, [1] http://www.openarchitectureware.org/pub/documentation/4.3.1/html/contents/core_reference.html#xpand_reference_introduction 2010/3/31 Dirk Haun > William Garcia wrote: > > >I already have a first draft of my proposal in > > > https://docs.google.com/Doc?docid=0AXpOuYbg8051ZGNyM3NyaGZfNzdnZGI5emdi&hl=en > > Thanks. The idea is really intriguing. > > Here's something I don't quite understand yet: So the model for the > generator is written in a modelling language. Who would need to know > this language? Someone who wants to write a plugin? Or only those that > want to update the generator? > > I have to look into this modelling language. My concern is that there's > some special knowledge required to maintain this generator in the > future. What would you suggest for transfer of that knowledge? > > bye, Dirk > > > -- > http://www.geeklog.net/ > http://geeklog.info/ > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://eight.pairlist.net/mailman/listinfo/geeklog-devel > -- William Fernando Garcia Mu?oz Estudiante Ingenieria de Sistemas Comunidad Universitaria de Software Libre Cusol- UIS Tel 312 557 4736 -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladvoic at gmail.com Thu Apr 1 06:36:55 2010 From: vladvoic at gmail.com (Vlad Voicu) Date: Thu, 1 Apr 2010 13:36:55 +0300 Subject: [geeklog-devel] GSoC Calendar Plugin Message-ID: Here is my Calendar Plugin proposal for GSoC [1], any feedback will be appreciated. [1] https://docs.google.com/Doc?docid=0Aeg-WUGILVoWZGc4NTdiNmZfMjYyZmZwbmY5ZGc&hl=en Regards, Vlad From suprsidr at flashyourweb.com Thu Apr 1 08:58:46 2010 From: suprsidr at flashyourweb.com (Wayne Patterson) Date: Thu, 1 Apr 2010 07:58:46 -0500 Subject: [geeklog-devel] Testing with Plugins (Twitter and Facebook status) (Mat?as Hern?ndez Arellano) Message-ID: @see http://www.flashyourweb.com/article.php?story=twitter_block1.1 -Wayne -------------- next part -------------- An HTML attachment was scrubbed... URL: From sam at theleathers.net Thu Apr 1 09:38:02 2010 From: sam at theleathers.net (Samuel Leathers) Date: Thu, 01 Apr 2010 09:38:02 -0400 Subject: [geeklog-devel] Calendar Plugin - Recurring Events Message-ID: <4BB4A1BA.7040004@theleathers.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I wanted to maybe start bouncing ideas around about how to implement recurring events. I started by taking an ical file exported from my google calendar to get an idea of how it stores it, thinking that might be a good way to structure the database to make generation of an ical file simple. Lets start a dialog about how is best to represent these events. This is a sample event: BEGIN:VEVENT CREATED:20100112T184020Z LAST-MODIFIED:20100228T063110Z DTSTAMP:20100228T063110Z UID:msfeaphkg5p9eedmff4ide7bjo at google.com SUMMARY:RPTM 120 STATUS:CONFIRMED RRULE:FREQ=WEEKLY;UNTIL=20100430T193500Z;BYDAY=MO,WE,FR DTSTART;TZID=America/New_York:20100111T153500 DTEND;TZID=America/New_York:20100111T162500 LOCATION:Hosler 026 SEQUENCE:1 TRANSP:OPAQUE X-MOZ-GENERATION:1 END:VEVENT The interesting parts are RRULE, DTSTART and DTEND. DTSTART and DTEND are the start/end times for the first event. RRULE has a frequency rule, an optional until rule, and in this case a by day rule. However; looking at the spec: http://www.kanzaki.com/docs/ical/rrule.html it can be minutely, hourly, daily, weekly, monthly and yearly. And each has it's own set of options. So how do we encode this in the database? Do we have a column for frequency, until, period, days, etc... But what about this scenario: The first Saturday that follows the first Sunday of the month, forever: DTSTART;TZID=US-Eastern:19970913T090000 RRULE:FREQ=MONTHLY;BYDAY=SA;BYMONTHDAY=7,8,9,10,11,12,13 How would you arrange that one in the database? I think having a bunch of columns for recurring events could get real ugly. My other thought was what if we mirror the ical structure in the database like so: columns: dtstart, dtend, rrule And then write an ical class with a parser for displaying calendar events. This could be slow (I don't know), but what if we augment this ical backend in the database with a cache? Ical already supports a UID field, so what if we cache calendar recurring events (dtstart, dtend no rrule) in a cache table that expands recurring events for that month and year (linked to uid of event it was built from). Then when someone views a future month, it adds that month to the cache, or a crontab could be set for off-peak hours to rebuild the cache for the upcoming year. The cache could also contain "ghost" events for reminders for events. So when someone has a remind me the day before, rather than parsing for the event, checking if it's the day before, it queries the cache instead, sees there is an event reminder linked to event uid of future event, sends that reminder to all users (with an ical file including the event, so they can import it directly into their calendar from their e-mail). Just some thoughts. Wondering what everyone thinks, especially Vlad, since he's writing a proposal for this plugin. Sam -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJLtKG6AAoJEF7J+Z7XDXx/qG8IAIQIfvui4hPMM8hDSquotF5P tONF5bxU202cbz9CraHF6VgD4Qe7ch6ACQoAU7l5gOd7OWihied5PUXrKybwspGq KhCyCX/N3/j0L/cNpNCQMtEvd26CTWGQfo2Z7zmRIP3QOt5vvw4dWbf1TF8fhBTL 0Z+Fj6uwcELpvhvZAYK30+AAMhPpv2Hz10vm9AoWAq72ZpKwkAHNaE4ndwxxcSCM l4UgTtcDV3pddDUdoPolRwCTZ33YM6iLKUEx0SslPpddX876e7It8rjZKnqmR4vD c9AXTgbVkvPFCuFaZl9aZke7L3fNnvRKqF157mT8KArvS7nfaD8tbMmEkkwpkIM= =Uz3t -----END PGP SIGNATURE----- From joe at ThrowingDice.com Thu Apr 1 10:50:32 2010 From: joe at ThrowingDice.com (Joe Mucchiello) Date: Thu, 01 Apr 2010 10:50:32 -0400 Subject: [geeklog-devel] Calendar Plugin - Recurring Events In-Reply-To: <4BB4A1BA.7040004@theleathers.net> References: <4BB4A1BA.7040004@theleathers.net> Message-ID: <0L07006XXD8GI3V0@mta4.srv.hcvlny.cv.net> At 09:38 AM 4/1/2010, Samuel Leathers wrote: >Just some thoughts. Wondering what everyone thinks, especially Vlad, >since he's writing a proposal for this plugin. Once there was a bounty to fix the calendar plugin and I wrote a lot of the fixes requested for the bounty. The patch for Geeklog 1.5.1 or 1.6.0 (I forget which) is in the download section http://www.geeklog.net/filemgmt/index.php?id=933 Feel free to look at it and/or steal from it. My personal life interfered with getting that beta ship shape and I ended up removing the recurring events stuff just to make a release as my life went to hell. The forums also have some posts about it. But I did design it and in the end I felt it required two tables. One stored the "event info" and basically looks like the existing table with a few extra fields. The recurring data was stored in a text field and was basically the vcard recurring info format. The other table is an "event instance" table, it too has most of the existing fields as well as a parent_id field so you can link it back to the original event. When you save a single event, an entry is entered into both tables. When you save a recurring event, one entry goes into the info table and multiple entries are placed into the instance table. You need a configuration parameter to limit how far into the future events are added to the instance table. This needs to be configurable because some websites work just fine with only 1 year of future events visible and some websites needs events 5 years in the future visible. How to make this work? The info table needs the recurring_data field to hold the info about when future events are. You also need a next_unrealized_instance datetime field. This field is null if all instances of the event are in the instance table. If however there are instances that exceed the cutoff date, this field contains the date of the instance that next exceeds the cutoff. Then you need a task in the scheduler to get a list of all events whose next_unrealized_instance datetime is greater than the now()+cutoff time. For each of these records, you add any missing future instances and update the next_unrealized_instance field. All the logic to build your calendar views would shift focus from the current table to the instance table. But this also means that buttons like "edit" need to be split out into "edit master event" and "edit this instance". Outlook does this with a popup. Part of the real problem is there is already pseudo-support for recurring events in that events can last multiple days. If you have a 3-day convention annually, you generally aren't going to schedule it as a recurring event since the details from year to year are usually pretty much different even if the venue stays the same. But I'm sure someone will want to see support of attending Day 2 only. On the plus side, adding these events to the instance table simplifies the select code. Needless to say there are a lot of hidden gotchas to recurring events. ---- 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/ From vladvoic at gmail.com Thu Apr 1 12:31:12 2010 From: vladvoic at gmail.com (Vlad Voicu) Date: Thu, 1 Apr 2010 19:31:12 +0300 Subject: [geeklog-devel] Calendar Plugin - Recurring Events In-Reply-To: <4BB4A1BA.7040004@theleathers.net> References: <4BB4A1BA.7040004@theleathers.net> Message-ID: On Thu, Apr 1, 2010 at 4:38 PM, Samuel Leathers wrote: > > I think having a bunch of columns for recurring events could get real > ugly. My other thought was what if we mirror the ical structure in the > database like so: > > columns: dtstart, dtend, rrule I think this is the right way also. > And then write an ical class with a parser for displaying calendar > events. This could be slow (I don't know), but what if we augment this > ical backend in the database with a cache? Ical already supports a UID > field, so what if we cache calendar recurring events (dtstart, dtend no > rrule) in a cache table that expands recurring events for that month and > year (linked to uid of event it was built from). Then when someone views > a future month, it adds that month to the cache, or a crontab could be > set for off-peak hours to rebuild the cache for the upcoming year. The > cache could also contain "ghost" events for reminders for events. You can check my application, I suggested a similar solution. Only generating for 2 years ahead. I also proposed a minimal database structure in my application and a solution for exceptions. I don't think a cronjob is the best approach, but generating when a user reaches the end of the half(as I suggested) or the end of pre-generated period like you suggested. I found interesting information about this matter here: [1] > The cache could also contain "ghost" events for reminders for events. > So when someone has a remind me the day before, rather than parsing for the > event, checking if it's the day before, it queries the cache instead, > sees there is an event reminder linked to event uid of future event, > sends that reminder to all users (with an ical file including the event, > so they can import it directly into their calendar from their e-mail). I think that just a field of Remind_me and one of remind_me_value will suffice. Once a day the function will look in the database for events of tomorrow, if there are any events marked as remind_me and the remind_me_value is 1 it will send the emails with the .ics attached. If the user selects remind me one week before, the script will look if 7 days ahead of this day is any event that has the remind_me field true and the remind_me_value = 7. That is pretty fast I think as you only check 1 day for events maybe 5 times for 5 different type of remind_me_value values. x probably equal to 3 (remind me a day before 2 days before, etc) This can be done with a cronjob on a certain hour of a day. > > Just some thoughts. Wondering what everyone thinks, especially Vlad, > since he's writing a proposal for this plugin. > [1] http://www.justatheory.com/computers/databases/postgresql/recurring_events.html I expect an opinion also, Regards, Vlad. From vladvoic at gmail.com Thu Apr 1 12:54:39 2010 From: vladvoic at gmail.com (Vlad Voicu) Date: Thu, 1 Apr 2010 19:54:39 +0300 Subject: [geeklog-devel] Calendar Plugin - Recurring Events In-Reply-To: References: <4BB4A1BA.7040004@theleathers.net> Message-ID: On Thu, Apr 1, 2010 at 7:31 PM, Vlad Voicu wrote: > On Thu, Apr 1, 2010 at 4:38 PM, Samuel Leathers wrote: > >> >> I think having a bunch of columns for recurring events could get real >> ugly. My other thought was what if we mirror the ical structure in the >> database like so: >> >> columns: dtstart, dtend, rrule > > I think this is the right way also. > Sorry, I misinterpreted this, I now realize that you wanted to keep the rrule as a string, not as a table. I suggested a table because it is easier to treat complex events and exceptions this way. I'll look deeper in the Ical format for recurring events, but as far as I know, it doesn't support exceptions from recurrence rules. If we decide we don't want exceptions, I think using Ical's format is the right way to do it. Sorry for the badly formated email above. Regards, Vlad. From aqrowles at gmail.com Thu Apr 1 13:01:41 2010 From: aqrowles at gmail.com (Anthony Rowles) Date: Thu, 1 Apr 2010 13:01:41 -0400 Subject: [geeklog-devel] Calendar Plugin - Recurring Events In-Reply-To: References: <4BB4A1BA.7040004@theleathers.net> Message-ID: On Thu, Apr 1, 2010 at 9:38 AM, Samuel Leathers wrote: > I think having a bunch of columns for recurring events could get real > ugly. My other thought was what if we mirror the ical structure in the > database like so: > > columns: dtstart, dtend, rrule > > And then write an ical class with a parser for displaying calendar > events. This could be slow (I don't know), but what if we augment this > ical backend in the database with a cache? I'm also writing a proposal for the calendar plugin, and I'll get into this in more detail there, but my design uses this approach for calculating recurring events - except I plan to do that work in the client (free scaling!). It'll almost certainly be faster than having the server do all the computations, and at the very least the wait time will occur after the page has loaded, giving the user something to look at while they wait for the events to populate, instead of staring at a blank page. I plan to store recurring events in a separate table, but with one additional field, a list of "exceptions". When the client requests events for a range (say, April 2010), it gets a set of single events for that range, and a set of recurring events that might fall in that range (based on dtstart/dtend). It then generates all instances of the recurring events that take place within the range it's currently displaying (in this case, April 2010), and adds those to its event list. If the user wants to change one instance of a recurring series (say, move next week's weekly meeting back one hour because of a conflict), we convert the event to a "single event", add it to the non-recurring table, and add the date/time to the list of exceptions for its parent recurring series. You just have to maintain a link to the parent in the database so you can delete the newly spawned "single events" if the user later wants to delete the entire recurring series. Here's a really great paper on the topic that describes a flexible way to write a recurring event parser (what he calls "temporal expressions"): http://martinfowler.com/apsupp/recurring.pdf. His examples are in Java but I think it can be done just fine in JavaScript. Using unions/intersections/differences between sets, you can create really powerful and complex recurrences (every 3rd week in the summer, etc) fairly easily. - Tony From vfuria at gmail.com Thu Apr 1 13:03:48 2010 From: vfuria at gmail.com (Vincent Furia) Date: Thu, 1 Apr 2010 11:03:48 -0600 Subject: [geeklog-devel] Calendar Plugin - Recurring Events In-Reply-To: References: <4BB4A1BA.7040004@theleathers.net> Message-ID: Like Joe, I had looked at adding recurring events to Geeklog in the past. All the research I did indicated that the only efficient way to handle recurring events to instantiate individual events. At the time I came up with an idea for representing the events in the database. There would be two tables, a recurring events table and an events table. The recurring events table would be similar to the events table, but in addition would hold information about how the events recur. It would also contain a "begin" and "end" dates for when individual events had already been generated. When a query is made to view events, it would check the recurring events table to see if that date range had been generated for the recurring events that apply to the query. If the query was outside the date range, more events to satisfy the query would be generated. (It would be necessary to somehow represent that all early and/or all late dates had already been generated). The events table would contain a foreign key or NULL to the recurring events table so events can be associated with the "parent" recursion. Also a field in the event table would indicate if the event was an exception, so changes could be made to individual events that are part of recursion. I'm not particularly attached to this implementation, but this entire discussion on recurring events is a good one to have to better flesh out design and implementation ideas. 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). Vlad, I was intrigued by postgresql recurring events solution you found. I'm not sure an entirely SQL implementation like that would work too well in Geeklog. Mostly because MySQL (the primarily used database) doesn't have nearly as efficient SQL functions as postgresql. I can be convinced otherwise though if that's the route someone wants to go down... Another difficult part of implementing recurring events is creating a GUI that is flexible in their creation without being confusing to the user. This is another problem with trying to implement the full recursion abilities of the iCal standard. There are many implementations that will work. But there are even more that won't scale at all on a large site with lots of recurring events. I'm looking forward to reviewing proposals for the Calendar plugin. On a side note, I can't review google docs proposals from work, so they'll have to wait til tonight to be looked at (~0300 GMT). -Vinny On Thu, Apr 1, 2010 at 10:31 AM, Vlad Voicu wrote: > On Thu, Apr 1, 2010 at 4:38 PM, Samuel Leathers > wrote: > > > > > I think having a bunch of columns for recurring events could get real > > ugly. My other thought was what if we mirror the ical structure in the > > database like so: > > > > columns: dtstart, dtend, rrule > > I think this is the right way also. > > > And then write an ical class with a parser for displaying calendar > > events. This could be slow (I don't know), but what if we augment this > > ical backend in the database with a cache? Ical already supports a UID > > field, so what if we cache calendar recurring events (dtstart, dtend no > > rrule) in a cache table that expands recurring events for that month and > > year (linked to uid of event it was built from). Then when someone views > > a future month, it adds that month to the cache, or a crontab could be > > set for off-peak hours to rebuild the cache for the upcoming year. The > > cache could also contain "ghost" events for reminders for events. > > You can check my application, I suggested a similar solution. Only > generating for > 2 years ahead. I also proposed a minimal database structure in my > application and > a solution for exceptions. > > I don't think a cronjob is the best approach, but generating when a > user reaches the > end of the half(as I suggested) or the end of pre-generated period > like you suggested. > I found interesting information about this matter here: [1] > > > The cache could also contain "ghost" events for reminders for events. > > So when someone has a remind me the day before, rather than parsing for > the > > event, checking if it's the day before, it queries the cache instead, > > sees there is an event reminder linked to event uid of future event, > > sends that reminder to all users (with an ical file including the event, > > so they can import it directly into their calendar from their e-mail). > > I think that just a field of Remind_me and one of remind_me_value will > suffice. > Once a day the function will look in the database for events of tomorrow, > if there are any events marked as remind_me and the remind_me_value is > 1 it will send > the emails with the .ics attached. If the user selects remind me one > week before, the > script will look if 7 days ahead of this day is any event that has the > remind_me field true and the > remind_me_value = 7. That is pretty fast I think as you only check 1 > day for events maybe 5 > times for 5 different type of remind_me_value values. x probably equal > to 3 (remind me a day > before 2 days before, etc) This can be done with a cronjob on a > certain hour of a day. > > > > > Just some thoughts. Wondering what everyone thinks, especially Vlad, > > since he's writing a proposal for this plugin. > > > > [1] > http://www.justatheory.com/computers/databases/postgresql/recurring_events.html > > I expect an opinion also, > Regards, > Vlad. > _______________________________________________ > 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: From vfuria at gmail.com Thu Apr 1 13:13:39 2010 From: vfuria at gmail.com (Vincent Furia) Date: Thu, 1 Apr 2010 11:13:39 -0600 Subject: [geeklog-devel] Calendar Plugin - Recurring Events In-Reply-To: References: <4BB4A1BA.7040004@theleathers.net> Message-ID: On Thu, Apr 1, 2010 at 10:54 AM, Vlad Voicu wrote: > Sorry, I misinterpreted this, I now realize that you wanted to keep > the rrule as a string, not as a table. I suggested a table because it > is easier to treat complex events and exceptions this way. I'll look > deeper in the Ical format for recurring events, but as far as I know, > it doesn't support exceptions from recurrence rules. If we decide we > don't want exceptions, I think using Ical's format is the right way to > do it. > iCal does support exceptions to recurring events. See http://tools.ietf.org/html/rfc5545#section-3.8.5, or more specifically http://tools.ietf.org/html/rfc5545#section-3.8.5.1. Section 3.8.5.1 specifically details recurring events. If you look at some of the examples in 3.8.5.3, you can see how the iCal standard can so some pretty crazy recursion rules. -Vinny -------------- next part -------------- An HTML attachment was scrubbed... URL: From vfuria at gmail.com Thu Apr 1 13:15:26 2010 From: vfuria at gmail.com (Vincent Furia) Date: Thu, 1 Apr 2010 11:15:26 -0600 Subject: [geeklog-devel] Calendar Plugin - Recurring Events In-Reply-To: References: <4BB4A1BA.7040004@theleathers.net> Message-ID: 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 On Thu, Apr 1, 2010 at 11:01 AM, Anthony Rowles wrote: > On Thu, Apr 1, 2010 at 9:38 AM, Samuel Leathers > wrote: > > I think having a bunch of columns for recurring events could get real > > ugly. My other thought was what if we mirror the ical structure in the > > database like so: > > > > columns: dtstart, dtend, rrule > > > > And then write an ical class with a parser for displaying calendar > > events. This could be slow (I don't know), but what if we augment this > > ical backend in the database with a cache? > > I'm also writing a proposal for the calendar plugin, and I'll get into > this in more detail there, but my design uses this approach for > calculating recurring events - except I plan to do that work in the > client (free scaling!). It'll almost certainly be faster than having > the server do all the computations, and at the very least the wait > time will occur after the page has loaded, giving the user something > to look at while they wait for the events to populate, instead of > staring at a blank page. > > I plan to store recurring events in a separate table, but with one > additional field, a list of "exceptions". When the client requests > events for a range (say, April 2010), it gets a set of single events > for that range, and a set of recurring events that might fall in that > range (based on dtstart/dtend). It then generates all instances of > the recurring events that take place within the range it's currently > displaying (in this case, April 2010), and adds those to its event > list. If the user wants to change one instance of a recurring series > (say, move next week's weekly meeting back one hour because of a > conflict), we convert the event to a "single event", add it to the > non-recurring table, and add the date/time to the list of exceptions > for its parent recurring series. You just have to maintain a link to > the parent in the database so you can delete the newly spawned "single > events" if the user later wants to delete the entire recurring series. > > Here's a really great paper on the topic that describes a flexible way > to write a recurring event parser (what he calls "temporal > expressions"): http://martinfowler.com/apsupp/recurring.pdf. His > examples are in Java but I think it can be done just fine in > JavaScript. Using unions/intersections/differences between sets, you > can create really powerful and complex recurrences (every 3rd week in > the summer, etc) fairly easily. > > - Tony > _______________________________________________ > 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: From aqrowles at gmail.com Thu Apr 1 13:33:09 2010 From: aqrowles at gmail.com (Anthony Rowles) Date: Thu, 1 Apr 2010 13:33:09 -0400 Subject: [geeklog-devel] Calendar Plugin - Recurring Events In-Reply-To: References: <4BB4A1BA.7040004@theleathers.net> Message-ID: It's an important policy decision, for certain. According to W3C, >95% of users browse with JavaScript enabled, and this percentage rises every year. Still, we should probably support graceful degradation - the parser would have to be written twice in PHP and JS, but it shouldn't be too difficult to port just a few classes, and it's functionality anyone with knowledge of PHP and JS could add later, if I don't have time during the summer. I'd implement the fallback solution using temporary tables - this prevents the generated events from interfering with the client-side solution, and since the number of JavaScript-disabled users is likely to be extremely low, the lack of caching shouldn't be an issue. A user with JS disabled is going to have a less responsive application, but a functioning one. - Tony On Thu, Apr 1, 2010 at 1:15 PM, Vincent Furia wrote: > 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 > > On Thu, Apr 1, 2010 at 11:01 AM, Anthony Rowles wrote: > >> On Thu, Apr 1, 2010 at 9:38 AM, Samuel Leathers >> wrote: >> > I think having a bunch of columns for recurring events could get real >> > ugly. My other thought was what if we mirror the ical structure in the >> > database like so: >> > >> > columns: dtstart, dtend, rrule >> > >> > And then write an ical class with a parser for displaying calendar >> > events. This could be slow (I don't know), but what if we augment this >> > ical backend in the database with a cache? >> >> I'm also writing a proposal for the calendar plugin, and I'll get into >> this in more detail there, but my design uses this approach for >> calculating recurring events - except I plan to do that work in the >> client (free scaling!). It'll almost certainly be faster than having >> the server do all the computations, and at the very least the wait >> time will occur after the page has loaded, giving the user something >> to look at while they wait for the events to populate, instead of >> staring at a blank page. >> >> I plan to store recurring events in a separate table, but with one >> additional field, a list of "exceptions". When the client requests >> events for a range (say, April 2010), it gets a set of single events >> for that range, and a set of recurring events that might fall in that >> range (based on dtstart/dtend). It then generates all instances of >> the recurring events that take place within the range it's currently >> displaying (in this case, April 2010), and adds those to its event >> list. If the user wants to change one instance of a recurring series >> (say, move next week's weekly meeting back one hour because of a >> conflict), we convert the event to a "single event", add it to the >> non-recurring table, and add the date/time to the list of exceptions >> for its parent recurring series. You just have to maintain a link to >> the parent in the database so you can delete the newly spawned "single >> events" if the user later wants to delete the entire recurring series. >> >> Here's a really great paper on the topic that describes a flexible way >> to write a recurring event parser (what he calls "temporal >> expressions"): http://martinfowler.com/apsupp/recurring.pdf. His >> examples are in Java but I think it can be done just fine in >> JavaScript. Using unions/intersections/differences between sets, you >> can create really powerful and complex recurrences (every 3rd week in >> the summer, etc) fairly easily. >> >> - Tony >> _______________________________________________ >> 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: From joe at ThrowingDice.com Thu Apr 1 13:52:10 2010 From: joe at ThrowingDice.com (Joe Mucchiello) Date: Thu, 01 Apr 2010 13:52:10 -0400 Subject: [geeklog-devel] Calendar Plugin - Recurring Events In-Reply-To: References: <4BB4A1BA.7040004@theleathers.net> Message-ID: <0L07006WVLMZSAL0@mta1.srv.hcvlny.cv.net> 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/ From aqrowles at gmail.com Thu Apr 1 14:27:33 2010 From: aqrowles at gmail.com (Anthony Rowles) Date: Thu, 1 Apr 2010 14:27:33 -0400 Subject: [geeklog-devel] Calendar Plugin - Recurring Events In-Reply-To: <0L07006WVLMZSAL0@mta1.srv.hcvlny.cv.net> References: <4BB4A1BA.7040004@theleathers.net> <0L07006WVLMZSAL0@mta1.srv.hcvlny.cv.net> Message-ID: 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 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: From sam at theleathers.net Thu Apr 1 14:42:35 2010 From: sam at theleathers.net (Samuel Leathers) Date: Thu, 01 Apr 2010 14:42:35 -0400 Subject: [geeklog-devel] Calendar Plugin - Recurring Events In-Reply-To: References: <4BB4A1BA.7040004@theleathers.net> <0L07006WVLMZSAL0@mta1.srv.hcvlny.cv.net> Message-ID: <4BB4E91B.3080605@theleathers.net> -----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----- From joe at ThrowingDice.com Thu Apr 1 14:57:22 2010 From: joe at ThrowingDice.com (Joe Mucchiello) Date: Thu, 01 Apr 2010 14:57:22 -0400 Subject: [geeklog-devel] Calendar Plugin - Recurring Events In-Reply-To: References: <4BB4A1BA.7040004@theleathers.net> <0L07006WVLMZSAL0@mta1.srv.hcvlny.cv.net> Message-ID: <0L070025WONN1XN0@mta5.srv.hcvlny.cv.net> 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/ From joe at ThrowingDice.com Thu Apr 1 15:03:21 2010 From: joe at ThrowingDice.com (Joe Mucchiello) Date: Thu, 01 Apr 2010 15:03:21 -0400 Subject: [geeklog-devel] Calendar Plugin - Recurring Events In-Reply-To: References: <4BB4A1BA.7040004@theleathers.net> Message-ID: <0L07008DEOXMG0D0@mta3.srv.hcvlny.cv.net> 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/ From Randy.Kolenko at nextide.ca Thu Apr 1 14:49:36 2010 From: Randy.Kolenko at nextide.ca (Randy Kolenko) Date: Thu, 1 Apr 2010 14:49:36 -0400 Subject: [geeklog-devel] Calendar Plugin - Recurring Events Message-ID: <063B8B70CB9DA141B2FC1DB483561B9F3834BC@nex-pluto.nextide.ca> 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 From sam at theleathers.net Thu Apr 1 15:11:37 2010 From: sam at theleathers.net (Samuel Leathers) Date: Thu, 01 Apr 2010 15:11:37 -0400 Subject: [geeklog-devel] Calendar Plugin - Recurring Events In-Reply-To: References: <4BB4A1BA.7040004@theleathers.net> Message-ID: <4BB4EFE9.4050000@theleathers.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/1/10 12:54 PM, Vlad Voicu wrote: > Sorry, I misinterpreted this, I now realize that you wanted to keep > the rrule as a string, not as a table. I suggested a table because it > is easier to treat complex events and exceptions this way. I'll look > deeper in the Ical format for recurring events, but as far as I know, > it doesn't support exceptions from recurrence rules. If we decide we > don't want exceptions, I think using Ical's format is the right way to > do it. I played with this in thunderbird (lightning), and from what I can tell, for exceptions it stores the same uid as the original event, it creating a new event identical to the first. So say every wednesday, recurring event at Sparks School However, Wednesday, the 24th it's been moved to Sparks Park, the original recurring event would remain the same, and the new event would drop the rrule, change the location, keep the same uid as the old event, change dtstart and dtend to this events date/time, and then add another rule called recurrence-id that appears to be the same as this events dtstart. Sam -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJLtO/pAAoJEF7J+Z7XDXx/xnIH/1snpfrKctpjHVDlND4itPHD Om0hJQ75A2o1ZyUyRIOV/iplZ5GzJcrYAkrp65DFwunPChxCDgmAnPWrc+zL/U8V SCHNNT17buk9y8rn/7zhZCNver+E6kCUy4Ccacxs+7Z1qQIH7dgE/YbUMl1IS5/H 9gZCliqjzfhQQYWfAOtS0miDyJfyue4gFE8GxOej7rMcL4ZPC867XFjZkesN5p8+ DZ1R15pkDwIfGxDdZisv4ZV1sYRdrizQwo1RT+9B33z4BVlpArJ/NnLeusoq7dLY 5j+ZknjNo3OqE0Chd3fUU/c0TYy/YmHqUJGoEqETT2W6H8qMn7n/8CwEIqmmoz0= =EDXY -----END PGP SIGNATURE----- From aqrowles at gmail.com Thu Apr 1 15:12:31 2010 From: aqrowles at gmail.com (Anthony Rowles) Date: Thu, 1 Apr 2010 15:12:31 -0400 Subject: [geeklog-devel] Calendar Plugin - Recurring Events In-Reply-To: <063B8B70CB9DA141B2FC1DB483561B9F3834BC@nex-pluto.nextide.ca> References: <063B8B70CB9DA141B2FC1DB483561B9F3834BC@nex-pluto.nextide.ca> Message-ID: 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 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: From vladvoic at gmail.com Thu Apr 1 17:11:35 2010 From: vladvoic at gmail.com (Vlad Voicu) Date: Fri, 2 Apr 2010 00:11:35 +0300 Subject: [geeklog-devel] Calendar Plugin - Recurring Events In-Reply-To: References: <063B8B70CB9DA141B2FC1DB483561B9F3834BC@nex-pluto.nextide.ca> Message-ID: On Thu, Apr 1, 2010 at 10:12 PM, Anthony Rowles wrote: > 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. > I was wondering how are you going to implement reminders for recurring events. Regards, Vlad. From nsiire at gmail.com Thu Apr 1 17:41:42 2010 From: nsiire at gmail.com (Agana-Nsiire Agana) Date: Thu, 1 Apr 2010 21:41:42 +0000 Subject: [geeklog-devel] Hello Hello! Message-ID: 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 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 > Subject: Re: [geeklog-devel] Calendar Plugin - Recurring Events > To: Geeklog Development > Message-ID: > > 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 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: > > > ------------------------------ > > Message: 2 > Date: Thu, 01 Apr 2010 14:42:35 -0400 > From: Samuel Leathers > Subject: Re: [geeklog-devel] Calendar Plugin - Recurring Events > To: Geeklog Development > 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 > Subject: Re: [geeklog-devel] Calendar Plugin - Recurring Events > To: Geeklog Development > 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 > Subject: Re: [geeklog-devel] Calendar Plugin - Recurring Events > To: Geeklog Development > 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" > Subject: Re: [geeklog-devel] Calendar Plugin - Recurring Events > To: "Geeklog Development" > 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 > ******************************************** > From aqrowles at gmail.com Thu Apr 1 18:31:01 2010 From: aqrowles at gmail.com (Anthony Rowles) Date: Thu, 1 Apr 2010 18:31:01 -0400 Subject: [geeklog-devel] Calendar Plugin - Recurring Events In-Reply-To: References: <063B8B70CB9DA141B2FC1DB483561B9F3834BC@nex-pluto.nextide.ca> Message-ID: Great question - of course it depends on the type of reminder. For a notification on login, etc. (user-initiated), it's not bad, but client-side processing makes something like automated emailed reminders pretty difficult. If you had to do it, you could probably do it with a post-back that flags events that need reminding out to some number of days, or maintains a "next occurance" field, which works if the user logs in semi-regularly, but it seems like a bit of a hack to me. If emailed reminders are necessary, a different design is probably superior. - Tony On Thu, Apr 1, 2010 at 5:11 PM, Vlad Voicu wrote: > On Thu, Apr 1, 2010 at 10:12 PM, Anthony Rowles > wrote: > > 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. > > > > I was wondering how are you going to implement reminders for recurring > events. > > > Regards, > Vlad. > _______________________________________________ > 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: From vfuria at gmail.com Thu Apr 1 18:44:09 2010 From: vfuria at gmail.com (Vincent Furia) Date: Thu, 1 Apr 2010 16:44:09 -0600 Subject: [geeklog-devel] Calendar Plugin - Recurring Events In-Reply-To: References: <063B8B70CB9DA141B2FC1DB483561B9F3834BC@nex-pluto.nextide.ca> Message-ID: Reminders are something we'd like to have, at the very least, the option to add in the future. There is also a "notification" GSoC project to develop a notification system. Once both the Calendars are tied in would seem a natural fit. -Vinny On Thu, Apr 1, 2010 at 4:31 PM, Anthony Rowles wrote: > Great question - of course it depends on the type of reminder. For a > notification on login, etc. (user-initiated), it's not bad, but client-side > processing makes something like automated emailed reminders pretty > difficult. If you had to do it, you could probably do it with a post-back > that flags events that need reminding out to some number of days, or > maintains a "next occurance" field, which works if the user logs in > semi-regularly, but it seems like a bit of a hack to me. If emailed > reminders are necessary, a different design is probably superior. > > - Tony > > > On Thu, Apr 1, 2010 at 5:11 PM, Vlad Voicu wrote: > >> On Thu, Apr 1, 2010 at 10:12 PM, Anthony Rowles >> wrote: >> > 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. >> > >> >> I was wondering how are you going to implement reminders for recurring >> events. >> >> >> Regards, >> Vlad. >> _______________________________________________ >> 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: From joe at ThrowingDice.com Thu Apr 1 22:57:33 2010 From: joe at ThrowingDice.com (Joe Mucchiello) Date: Thu, 01 Apr 2010 22:57:33 -0400 Subject: [geeklog-devel] GSoC 2010 is on In-Reply-To: <0KXY00KZWWY7QU11@mta4.srv.hcvlny.cv.net> References: <063B8B70CB9DA141B2FC1DB483561B9F11229F@nex-pluto.nextide.ca> <0KXY009MP59JSA20@mta2.srv.hcvlny.cv.net> <8319e2d61002161455l49213d86ned2c9afc1bc697c1@mail.gmail.com> <0KXY00KZWWY7QU11@mta4.srv.hcvlny.cv.net> Message-ID: <0L0800HIGAW99VQ0@mta5.srv.hcvlny.cv.net> Replying to myself from 6 weeks ago. This was the thread where I proposed the changes to gl_groups to support user defined groups for use by the socnet plugin. At 12:10 AM 2/17/2010, Joe Mucchiello wrote: >I would offer to write the patch but I don't have a good track >record with getting my patches accepted into core. That lack of acceptance is mostly my fault because, like this patch, I usually submit them just as core is upgrading and my patches end up being behind by a version. With all the enthusiasm for socnet I'm hoping this one will be the exception. Regardless, I created the patch. It wasn't that hard. Since I have no mercurial access, I've created a feature request in the bug tracker and attached a zip file contain the just under 30 files that needed to be updated. I've tested it out as well as I could without a socnet plugin to test against. http://project.geeklog.net/tracking/view.php?id=1106 The feature request has all the details needed to apply the patch to stock 1.6.1, upgrade, and play around with it. For review, there is a new field on gl_groups called grp_owner. When that field is zero, the group is considered a system group. When the field is non-zero, that uid owns the group. What it means to own a group is not detailed anywhere in core. All that this patch does to core is ensure that all core access to the gl_groups table includes the where clause 'grp_owner = 0'. There are some issues with $_GROUPS as detailed in the feature request but they are not an issue for core. They are an issue for other plugins. Joe ---- 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.176). http://www.pctools.com/free-antivirus/ From sushilm.iitb at gmail.com Fri Apr 2 00:44:12 2010 From: sushilm.iitb at gmail.com (sushil meena) Date: Fri, 2 Apr 2010 10:14:12 +0530 Subject: [geeklog-devel] Fwd: doubt regarding bug number 965 In-Reply-To: References: Message-ID: hey, Can anyone please tell me how to reproduce bug number 965. I have tried a lot of documentation. But could not get to this. What I have is geeklog installed from mercurial repositories and default professional theme. Please help me in this regard. thanking you in anticipations -- sushil kumar meena, second year undergraduate, computer science and engineering department, IIT BOMBAY -------------- next part -------------- An HTML attachment was scrubbed... URL: From vfuria at gmail.com Fri Apr 2 01:04:54 2010 From: vfuria at gmail.com (Vincent Furia) Date: Thu, 1 Apr 2010 23:04:54 -0600 Subject: [geeklog-devel] Geeklog Development Virtual Machine Message-ID: I've created a Virtual Machine for Geeklog development so that any user (looks toward GSoC students) who wants to get up and running quickly with Geeklog can do so. Just down the virtual machine at: http://project.geeklog.net/attachments/Geeklog_Devel.i686-1.0.0.vmx.tar.bz2 Then you can use VMWare (including the free "player") or Virtual Box (GPL) to run the Geeklog Devel Virtual Machine. When you initially log on as the "geeklog" user (password: "geeklog"), it will automatically clone the Mercurial repository to get the latest Geeklog. It also populates the database for you with all the defaults. Enjoy. Please let me know how it works for you. Thanks, Vinny -------------- next part -------------- An HTML attachment was scrubbed... URL: From vfuria at gmail.com Fri Apr 2 01:39:51 2010 From: vfuria at gmail.com (Vincent Furia) Date: Thu, 1 Apr 2010 23:39:51 -0600 Subject: [geeklog-devel] GSoC 2010 is on In-Reply-To: <0L0800HIGAW99VQ0@mta5.srv.hcvlny.cv.net> References: <063B8B70CB9DA141B2FC1DB483561B9F11229F@nex-pluto.nextide.ca> <0KXY009MP59JSA20@mta2.srv.hcvlny.cv.net> <8319e2d61002161455l49213d86ned2c9afc1bc697c1@mail.gmail.com> <0KXY00KZWWY7QU11@mta4.srv.hcvlny.cv.net> <0L0800HIGAW99VQ0@mta5.srv.hcvlny.cv.net> Message-ID: Joe, Only had a few minutes tonight to take a look. Have a couple comments though: 1. 1.7.0 introduces Postgresql support, we'll need SQL updates for it as well. 2. Since your using the column grp_owner in where clauses everytime you select from the group table, I think we need an index on it. I think the UNIQUE INDEX in MySQL also acts as sorting index, but I don't think (but I'm not sure) that a MSSQL CONSTRAINT acts as an index. I'll have more time to look at it over the weekend. -Vinny P.S. You may be a bit late for 1.7.0. Dirk indicated a feature freeze earlier this week and is aiming for a Beta 1.7.0 over the weekend. On Thu, Apr 1, 2010 at 8:57 PM, Joe Mucchiello wrote: > Replying to myself from 6 weeks ago. This was the thread where I proposed > the changes to gl_groups to support user defined groups for use by the > socnet plugin. > > > At 12:10 AM 2/17/2010, Joe Mucchiello wrote: > >> I would offer to write the patch but I don't have a good track record with >> getting my patches accepted into core. >> > > That lack of acceptance is mostly my fault because, like this patch, I > usually submit them just as core is upgrading and my patches end up being > behind by a version. With all the enthusiasm for socnet I'm hoping this one > will be the exception. > > Regardless, I created the patch. It wasn't that hard. Since I have no > mercurial access, I've created a feature request in the bug tracker and > attached a zip file contain the just under 30 files that needed to be > updated. I've tested it out as well as I could without a socnet plugin to > test against. http://project.geeklog.net/tracking/view.php?id=1106 The > feature request has all the details needed to apply the patch to stock > 1.6.1, upgrade, and play around with it. > > For review, there is a new field on gl_groups called grp_owner. When that > field is zero, the group is considered a system group. When the field is > non-zero, that uid owns the group. What it means to own a group is not > detailed anywhere in core. All that this patch does to core is ensure that > all core access to the gl_groups table includes the where clause 'grp_owner > = 0'. There are some issues with $_GROUPS as detailed in the feature request > but they are not an issue for core. They are an issue for other plugins. > > Joe > > > > ---- > 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.176). > > 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: From joe at ThrowingDice.com Fri Apr 2 02:00:25 2010 From: joe at ThrowingDice.com (Joe Mucchiello) Date: Fri, 02 Apr 2010 02:00:25 -0400 Subject: [geeklog-devel] GSoC 2010 is on In-Reply-To: References: <063B8B70CB9DA141B2FC1DB483561B9F11229F@nex-pluto.nextide.ca> <0KXY009MP59JSA20@mta2.srv.hcvlny.cv.net> <8319e2d61002161455l49213d86ned2c9afc1bc697c1@mail.gmail.com> <0KXY00KZWWY7QU11@mta4.srv.hcvlny.cv.net> <0L0800HIGAW99VQ0@mta5.srv.hcvlny.cv.net> Message-ID: <0L0800JZRJCSPWQ0@mta1.srv.hcvlny.cv.net> At 01:39 AM 4/2/2010, Vincent Furia wrote: >Only had a few minutes tonight to take a look. Have a couple comments though: > >1. 1.7.0 introduces Postgresql support, we'll need SQL updates for >it as well. Yeah, I know. I can read the docs and make something up. But someone more familiar with pgsql should write that. If I had been targeting 1.7.0 directly, I'd have created the files at a minimum. I just figured 1.7.0 is a moving target and a 3-way merge with mercurial should be easier than it use to be with CVS. Someone just needs to checkout from the 1.6.1 commit. Merge my changes and then try to push the changes back up. (Although, I admit, for me this is just my understanding of the theory behind a DVCS.) >2. Since your using the column grp_owner in where clauses everytime >you select from the group table, I think we need an index on it. I >think the UNIQUE INDEX in MySQL also acts as sorting index, but I >don't think (but I'm not sure) that a MSSQL CONSTRAINT acts as an index. Again, I just mirrored what I saw in the mssql files. If what you say is true there are potentially no indexes (other than primary key indexes) on the mssql install as I see no place where a CREATE INDEX statement is executed. Unfortunately I don't have anywhere to run mssql to test it out. Ultimately, I wasn't worried about indexes on the database because they can always be tweaked ad hoc in a worst case scenario. Besides, Geeklog is lousy about indexes. If you've ever upgraded a database continuously from an early version you might end up with duplicate indexes on various tables. >I'll have more time to look at it over the weekend. Thanks. >P.S. You may be a bit late for 1.7.0. Dirk indicated a feature >freeze earlier this week and is aiming for a Beta 1.7.0 over the weekend. I always miss the feature freeze emails. Looking back he didn't actually call it a feature freeze. Just a beta this weekend. I sent him an email about this yesterday that he didn't answer. So I can still hope this time I made it under the wire. Technically I suppose this only needs to be part of 1.7.1hg so that GSoC devs can use it. ---- 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.176). http://www.pctools.com/free-antivirus/ From msdark at archlinux.cl Fri Apr 2 02:57:20 2010 From: msdark at archlinux.cl (=?ISO-8859-1?B?TWF07WFzIEhlcm7hbmRleg==?= Arellano) Date: Fri, 2 Apr 2010 03:57:20 -0300 Subject: [geeklog-devel] Idea fro Issue 0001068 Message-ID: <20100402035720.015db6b4@archlinux.cl> http://project.geeklog.net/tracking/view.php?id=1068 I have and idea to do that.. write a function in lib-custom.php using jsmin-php. The idea is that the function CUSTOM_compressJS obtained from a specific directory (the path to the JS file as a parameter of the function) each of the files. This function returns the JavaScript code archives. Now the question: How should I write that function? Here's an example: function CUSTOM_compressJS ( $jsdir ){ / ** Files are read from the directory and are stored in an array * / require_once(jsmin.php); $param = ''; for ( $i=0; $i < count($jsFiles); $i++ ){ $param += file_get_contents($jsFiles[i]); } return JSMin::minify($param); } is that correct? Or is better write a plugin to do that?... But I think that kind of function should be defined within the system From dirk at haun-online.de Fri Apr 2 03:14:55 2010 From: dirk at haun-online.de (Dirk Haun) Date: Fri, 2 Apr 2010 09:14:55 +0200 Subject: [geeklog-devel] Geeklog Development Virtual Machine In-Reply-To: References: Message-ID: <20100402071455.472201710@smtp.haun-online.de> Vincent Furia wrote: >I've created a Virtual Machine for Geeklog development so that any user >(looks toward GSoC students) who wants to get up and running quickly with >Geeklog can do so. Just down the virtual machine at: > >http://project.geeklog.net/attachments/Geeklog_Devel.i686-1.0.0.vmx.tar.bz2 It's actually ...tar.gz, not .bz2 :) Thanks, Vinny! bye, Dirk -- http://www.haun-online.de/ http://spam.tinyweb.net/ From dirk at haun-online.de Fri Apr 2 03:11:33 2010 From: dirk at haun-online.de (Dirk Haun) Date: Fri, 2 Apr 2010 09:11:33 +0200 Subject: [geeklog-devel] Fwd: doubt regarding bug number 965 In-Reply-To: References: Message-ID: <20100402071133.268904238@smtp.haun-online.de> sushil meena wrote: >Can anyone please tell me how to reproduce bug number >965. I've attached a screenshot. Does that help? If not, please explain in more detail what your problem is. bye, Dirk -- http://www.geeklog.net/ http://geeklog.info/ From tuxcanfly at gmail.com Fri Apr 2 04:35:25 2010 From: tuxcanfly at gmail.com (Jakh Daven) Date: Fri, 2 Apr 2010 14:05:25 +0530 Subject: [geeklog-devel] GSoC 2010 is on In-Reply-To: <0L0800JZRJCSPWQ0@mta1.srv.hcvlny.cv.net> References: <063B8B70CB9DA141B2FC1DB483561B9F11229F@nex-pluto.nextide.ca> <0KXY009MP59JSA20@mta2.srv.hcvlny.cv.net> <8319e2d61002161455l49213d86ned2c9afc1bc697c1@mail.gmail.com> <0KXY00KZWWY7QU11@mta4.srv.hcvlny.cv.net> <0L0800HIGAW99VQ0@mta5.srv.hcvlny.cv.net> <0L0800JZRJCSPWQ0@mta1.srv.hcvlny.cv.net> Message-ID: Hi Joe, I am a would-be GSoC student participant and I am interested in taking up the Socnet project. I will go through your patch, test it during the weekend and try to figure out how it fits in with socnet. I have glanced through the documentation in the feature request and I would like to add a few points on how Socnet will handle this in my view. From the feature request page: Code displaying this (such as SOC_getGroupDropdown) would need to handle how > to display the group names intelligently. > Will the group names in the drop down be unique?. If yes, we will need to get the user name from the uid and attach it to the group name (since group names are not unique). For example the drop down would contain the following items: - Joe Mucchiello's Friends - Jakh Daven's Co-Workers - Jakh Daven's Friends Is this correct? We will need to handle user name+group name clashes somehow. As you said, even if it does not make it into 1.7.0, it will be very useful to the gsoc devs, Thanks for the patch. Cheers, Jakh On Fri, Apr 2, 2010 at 11:30 AM, Joe Mucchiello wrote: > At 01:39 AM 4/2/2010, Vincent Furia wrote: > >> Only had a few minutes tonight to take a look. Have a couple comments >> though: >> >> 1. 1.7.0 introduces Postgresql support, we'll need SQL updates for it as >> well. >> > > Yeah, I know. I can read the docs and make something up. But someone more > familiar with pgsql should write that. If I had been targeting 1.7.0 > directly, I'd have created the files at a minimum. I just figured 1.7.0 is a > moving target and a 3-way merge with mercurial should be easier than it use > to be with CVS. Someone just needs to checkout from the 1.6.1 commit. Merge > my changes and then try to push the changes back up. (Although, I admit, for > me this is just my understanding of the theory behind a DVCS.) > > > 2. Since your using the column grp_owner in where clauses everytime you >> select from the group table, I think we need an index on it. I think the >> UNIQUE INDEX in MySQL also acts as sorting index, but I don't think (but I'm >> not sure) that a MSSQL CONSTRAINT acts as an index. >> > > Again, I just mirrored what I saw in the mssql files. If what you say is > true there are potentially no indexes (other than primary key indexes) on > the mssql install as I see no place where a CREATE INDEX statement is > executed. Unfortunately I don't have anywhere to run mssql to test it out. > Ultimately, I wasn't worried about indexes on the database because they can > always be tweaked ad hoc in a worst case scenario. Besides, Geeklog is lousy > about indexes. If you've ever upgraded a database continuously from an early > version you might end up with duplicate indexes on various tables. > > > I'll have more time to look at it over the weekend. >> > > Thanks. > > > P.S. You may be a bit late for 1.7.0. Dirk indicated a feature freeze >> earlier this week and is aiming for a Beta 1.7.0 over the weekend. >> > > I always miss the feature freeze emails. Looking back he didn't actually > call it a feature freeze. Just a beta this weekend. I sent him an email > about this yesterday that he didn't answer. So I can still hope this time I > made it under the wire. Technically I suppose this only needs to be part of > 1.7.1hg so that GSoC devs can use it. > > > ---- > 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.176). > 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: From joe at ThrowingDice.com Fri Apr 2 06:24:37 2010 From: joe at ThrowingDice.com (Joe Mucchiello) Date: Fri, 02 Apr 2010 06:24:37 -0400 Subject: [geeklog-devel] GSoC 2010 is on In-Reply-To: References: <063B8B70CB9DA141B2FC1DB483561B9F11229F@nex-pluto.nextide.ca> <0KXY009MP59JSA20@mta2.srv.hcvlny.cv.net> <8319e2d61002161455l49213d86ned2c9afc1bc697c1@mail.gmail.com> <0KXY00KZWWY7QU11@mta4.srv.hcvlny.cv.net> <0L0800HIGAW99VQ0@mta5.srv.hcvlny.cv.net> <0L0800JZRJCSPWQ0@mta1.srv.hcvlny.cv.net> Message-ID: <0L0800H5OW4F32W0@mta1.srv.hcvlny.cv.net> That scenario should not come up. Groups are not reciprocal and they are not necessarily public. A user who wants to set the group permission of a socnet object should only see his personal groups in the drop down. Just because you've added me to one of the group lists you want to maintain doesn't mean I can see that group. The socnet plugin will need to figure out how to differentiate between "Jakh's Private List of People He Sends Joke Links To" and "The New Jersey PHP User Group". In the first case, the list is only used by Jakh to create Links and share them with Jakh's friends. The people on the list see the links but cannot examine the list since it's private. The second list is obviously supposed to be public and every member of that list should be able to set permissions of an object to include that list. This is why the core code stays away from user owned groups. The context of what the user owned groups mean is not understood by core. It is only understood by the socnet plugin. In my original proposal there were several kinds of groups and rules for inviting people into public groups and approval systems for groups and how reciprocal friendship works, and so on. None of that is in the patch. The patch contains only what is minimally sufficient to allow all of that stuff to be written as part of a plugin. Someone still has to come up with all those rules and determine how they will be enforced and how they will be conveyed to the user via the browser. None of that is core's business. As the feature request in the bug tracker explains, there is a downside to this. Currently there is a global in Geeklog $_GROUPS. It contains the list of all groups the currently logged on user is a member of. It is used by SEC_inGroup to determine if the current user is a member of a group. It is also commonly used in SQL statements of the form: "WHERE group_id in (" . explode(',', $_GROUPS) . ')'; to select a set of objects to which the current user has permission to view. That all is unchanged. The problem is the dropdown box created by SEC_getGroupDropdown. This function also attempts to use the $_GROUPS array to create a list of