Subject: LibiCal Architecture

From: Frank_Dawson/CAM/[email-masked]
Date: Wed, 2 Jun 1999 17:24:09 -0400

Eric:

From the http://softwarestudio.org/libical/icalarch.html website, it is not
clear if the architecture will provide support for generating
iCalendar/iTIP/iMIP compliant MIME entities from calls to the API. Does it?
However, it was clear that it will parse it into a tree for further query by the
API.

I know I should ask this question to the iCalAPI mailing list, but though a
short Q&A wouldn't offend anyone. Sorry if it does...

-- Frank

---

From: Eric Busboom <[email-masked]>
Date: Thu, 03 Jun 1999 16:59:25 -0700

>short Q&A wouldn't offend anyone. Sorry if it does...

Well, it is certainly better than yet another "unsubscribe" message, and I am happy to indulge. I will copy libical, and we can pick this up again over there. I will leave this reply on ietf-calendar because it is related to how the structure of the protocol is reflected in the libical interface. 

>However, it was clear that it will parse it into a tree for further query by  the API.

Something that I really like about the core object spec is that it has a logical structure that has a natural in-machine representation. ( In fact, it is structured enough that maybe we could do an XML interface! Oh, yeah, sorry....)  The libical interface is almost a direct copy of the core object structure, except where I noted in a previous email. 

One break in the model is that there is no single top level container of components. An iMIP message can have several VCALENDAR components ( and VTIMEZONE?  I forget ) but those components are connected only through the MIME multi-part message that contains them. Conceptually, it would be nice if the set of VCALENDAR and other components could be collects by an component defined in the core object specification. 

This would be nice, because libical will probably have to implement it that way to keep the containment and access model consistent. Parsing an iMIP message can result in several VCALENDAR components, as well as other data, and I have to return all of them to the user. A container object is the logical choice, so, naturally, I'd prefer to have it be part of the spec. I can dream, right? 

Anyway, this is the MIME connection: Converting the top level container to a string will produce MIME data, but converting any other component, property, value, or parameter to a string will result in iTIP data, without MIME encapsulation. Someday, I will update the architecture document to indicate this. 

eric.