Fwd: Re: [kronolith] I'm having a problem with the kronolith_driver_sql class.

[Jan Schneider]

----- Weitergeleitete Nachricht von green@UMDNJ.EDU -----
    Datum: Sun, 15 Sep 2002 16:41:58 -0400
    Von: Cliff Green <green@UMDNJ.EDU>
Antwort an: Cliff Green <green@UMDNJ.EDU>
 Betreff: Re: [kronolith] I'm having a problem with the 
kronolith_driver_sql class.
      An: Jan Schneider <jan@horde.org>

Quoting Jan Schneider <jan@horde.org>:

[munch] 
> ics importing happens in Event::fromiCalendar().
Thanks!  I've added clauses here to get LOCATION and CATEGORY;  location seems
to work, but category doesn't.  I was more interested in being sure location
did.  I don't quite understand how we were getting it before.

> ics parsing happens in Data/imc.php and Data/icalendar.php.
Yeah, I've added a few things in both of these, too.  E.g.:

-timezone offset, to send in UTC form and to correct back to local time on
import
-ratcheted VCal Version to 2.0
-changed PRODID a little
-added METHOD:REQUEST, TRANSP:OPAQUE, ORGANIZER (which we don't have a place to
store just yet ;-)

The main thing was to deal with the offset, which didn't seem to translate
properly outside of kronolith.

At this point, I'm more interested in function _build() in icalendar.php, which
is where the incoming iCal material is parsed into objects, etc., right?  I'm
concerned initially about VTIMEZONE and VALARM.  I don't know about other
calendar/scheduling packages (e.g., GroupWise, Domino, etc., but Evolution
insists on sending a VTIMEZONE object just above any VEVENT objects, and LookOut
sends VALARM by default if you don't uncheck it (which I'm sure most users don't
even see, let alone think about).

c
-- 
Cliff Green
Academic Computing Services - UMDNJ
Signature under NDA

----- Ende der weitergeleiteten Nachricht -----


Jan.

--
http://www.horde.org - The Horde Project
http://www.ammma.de - discover your knowledge
http://www.tip4all.de - Deine private Tippgemeinschaft