[chandler-dev] chandler2 and vobject

Jeffrey Harris jeffrey at osafoundation.org
Mon Dec 8 16:12:03 PST 2008


Hi Jared,

> Jeffrey and I had chatted briefly about chandler2's relationship to
> vobject.  I'm not sure how to proceed along those lines so I'm asking
> for suggestions.

Sorry it took me a little while to respond; here are my thoughts on this.

> It might be neat to be able to work with a Chandler2 Event() as a
> vobject.

Having a direct connection between vobject and chandler2 data structures
would be great, and I think there's a lot of low hanging fruit.

Chandler_one's sharing architecture progressed something like this:

1. chandler1 event -> vobject VEVENT (direct translation)
2. chandler1 event -> EIM -> vobject VEVENT

Happily, when we did this, our tests converted over almost without
change.  It seems pretty reasonable to do something similar with
chandler2 (I'm currently working on EIM import/export).  If you can
write your tests in such a way that I can drop in a different export
module and re-use your tests when I (or you!) do the EIM -> vobject
phase, that'd be nice.

> Something like:
> print event.as_vobject.serialize()

This syntax has the virtue that it's readable, and it suggests that
introspection on an event will reveal to you that this transformation is
available.

The downside is that it would tie Event to vobject pretty tightly.
We've been trying to avoid dependencies like this in chandler2.

The first alternate syntax that comes to mind is something like:

print Shared(event._item).as_vobject.serialize()

Right now ItemAddOns (which is what Shared would be, I think) only apply
to items, you can't do Shared(event) and get the same thing as
Shared(event._item) like you could in Chandler_one.  Might be worth
thinking about whether adding that syntactic sugar is desirable.

Anyway, I'm thinking you might write an ItemAddOn called ICalendar such
that:

ICalendar(event._item).as_vobject.serialize()

does what you want.  But I'm not at all wedded to this approach.  Seems
like it might be all around cleaner to just write a stand alone function:

from icalendar import as_vobject
as_vobject(event)

> -----
> 
> Even neater (for right now), would be to create new
> chandler.event.Events from a vobject.  With this pattern, one could
> write a pretty small "loop over an ics using vobject and create a set of
> chandler2 Events that correspond".
> 
> -----
> 
> coll = chandler.core.Collection(title='cal')
> for vevent in vobject(file='test.ics'):
>   coll.add(Event(from_ics=vevent))

Note that currently Collection.add() expects an item, not an Event.

Again, I could see two approaches:

item = Item()
ICalendar(item).from_vobject(vevent)

or just

new_item = item_from_vobject(vevent)

But the major wrinkle here is recurrence.  A simple loop unfortunately
doesn't cut it if recurrence is in play; a modification to a recurring
series may be serialized before or after the master, and you need to
link the modification up to the master.

Really, item_from_vobject needs to apply to a batch of VEVENTs, and
something like as_vobject applied to a chandler2 item may return
multiple VEVENT objects.

Sincerely,
Jeffrey



More information about the chandler-dev mailing list