[Zug-sig] Aggregating User Group Calendars

[Chris Calloway]

On 2/14/2008 11:49 AM, Alex Clark wrote:
> Hmmmm, anything on this yet? Assuming you want a "full page" calendar
> (similar to CalendarX, which has seen some Plone3 development recently,
> although I don't know the current state) I wonder if it would be
> totally out of the question to parse up some feeds and then create
> actual events on the site (then it would be easy to display them in
> the calendar).Just for reference, CalendarX was just re-released for Plone 3 last month. It is a product which provides a nice calendar view for just plain Plone events. I like 10x mo' bettah than the Plone4Artists calendar.

I hit reply earlier and it went to Tres. I'll reframe:

I just went through an eval of all the Plone 3 calendar products for my 
organization.

CalendarX is far and away the best and it was just re-released for Plone 
3 last month.

The problem is, I don't know of a Plone 3 (or any Plone) calendar 
product which aggregates event feeds into a master calendar. They all 
provide a calendar view for event objects on the site itself.

You might be able to re-tool a good starting point like CalendarX into
a feed aggregator. CalendarX is more of an updating of a Zope 2 product
for Plone into something that works well enough for Plone 3. While 
Plone4ArtistsCalendar is proceeding on more of a Zope 3 component path, 
it is still in an unreleased state for Plone 3. Plus, CalendarX just 
looks and acts so much better and the Plone 3 version is so damn 
configurable through Plone itself instead of the ZMI. The use cases for 
it seem very well thought out.

Particularly ugly are the Plone products which take event
feeds and dump them into ordinary Plone event objects on the aggregated 
end (and there are a few such products). That might get what we need. 
Bake event feeds into event objects on zope.org and then the calendar 
products "just work." Low hanging fruit.

I don't know how changes to the original event items being fed get 
translated into changes on the aggregated objects using that approach, 
however. It depends on things like short names not changing or 
overlapping, and that just isn't going to happen. And it's all kind of 
contrary to how feed aggregation is supposed to work.

A cleaner way might be this:

http://plone.org/products/collective.portlet.feedmixer/

But that requires some work to make a mutant product out of both 
feedmixer (or some feed aggregator) and CalendarX (or some calendar 
product). The beautiful thing about CalendarX and other Plone calendar 
products is they simply provide views for plain Plone event items, 
rather than having content types of their own. Sticking feeds into them 
is a fundamental change in how they work.

And then finally, the worst part of all. Plone event feeds out of the 
box are sorted by *modification date* instead of start date. How brain 
dead is that? It means everyone giving us a feed, assuming their feeds 
are coming from Plone sites, will need to be hacked on the sending end. 
The Plone event portlet gets it right. But the generic Plone RSS skin 
goes by modification date as though one feed skin can rule all content 
types. When event feeds are limited to five or ten items, you might not 
even see the most recently starting events if even past events have been 
more recently modified. As I can attest happens a lot.

And then there are the variety of event feeds. Not all ZUGs have a Plone 
site. :)

I suggested to Tres the lowest hanging fruit might be getting user 
groups to be religious about duplicating their event posts on zope.org. 
Although I know from experience that kind of effort both doesn't last 
long nor would it be widely adopted.

-- 
Sincerely,

Chris Calloway
http://www.secoora.org
office: 332 Chapman Hall   phone: (919) 599-3530
mail: Campus Box #3300, UNC-CH, Chapel Hill, NC 27599