Subject: Pseudo-components

From: Eric Busboom <[email-masked]>
Date: Thu, 03 Jun 1999 11:23:53 -0700

The following are notes that I have from my experience in implementing a C library for the iCAL core objects and iTIP. ( see http://softwarestudio.org/libical/ )  I have several notes, so I will send several emails, one topic per email, to make discussions easier to sort out. 

eric. 

---------------------------------------------------------------------------------------------------------------------- 

Pseudo-Components
-----------------

There are several instances of pseudo-components that implementations will probably represent as components. 

VTIMEZONE has STANDARD and DAYLIGHT, which are syntactically identical to components, but are not components. The most sensible way to implement them is as separate components, so why not promote them to components? AKAIK, the only difference would be adding a "V" to their names. 

VALARM has four different sets of rules for what properties that it may contain, differentiated by the ACTION property. I cannot make a interface to VALARM that syntactically restricts clients to calling only those accessors that are permitted according to the value of ACTION, so I will have to make four different classes, one to enforce each rule set, Perhaps VALARM should be split into four components? This would create a new component for each of the alarm types:

	AUDIO 
	EMAIL 
	PROC 
	DISPLAY

I think that any implementation that wants to enforce strong interfaces will create classes for each of these pseudo objects, because the semantics of each are very different.  It would be best if the spec also had these components, so it could be implemented exactly.

eric.