Subject: Re: Multiple types for properties

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

Eric:

One of the assumptions you are making is that everyone will need to make use of
a standard iCalendar API for their implementation. I don't think that this is
the case.

The primary focus to me is the protocols and formats, not the APIs. I think that
API technology is very fickle to programmers. Today it is C++ or Java, yesterday
it was C. Tomorrow?? Who knows. Yet, the standard formats and protocols defined
by RFC 2445, 2446 and 2447 will go on being referenced.

In regard to your comments about changing the date/time formats that are
accepted by your API, I would much rather have companion functions (in your C
Language binding) that can convert archaic, platform specific date/time formats
into and out of the standardized formats (e.g., the ISO 8601) formats.

Strong data typing. I think that monolythic data typing is certainly a
philosophical issue. Not everyone would agree that designing ATTACH or other
properties to take a single data type is best.

There is another alternative for the properties that take either a BINARY or a
URI value type. Require that the value be presented in only one of these forms.
For example, if you want to create an event with a ATTACH property, maybe your
API has a separate function to get/put the binary attachment resource in to the
calendar store's backend (which would return a URI type of handle to the object)
and a separate function to actually create the ATTACH property. This way, you
have address your tighter data model design principal but do it more simply.

In other cases, there is good reason that some of the date/time related
properties take on different value types. It is probably an over simplification
if you create an aggregate data type for DATE, DATE-TIME, PERIOD and DURATION.
Some time lords view the differences between these standard value types as
distinct as INT and FLOAT! But, you could very well create such a ISO8601 type
;-)

Your URL to Software Studios references your iCalendar API as being an "open
source" implementation. However, I couldn't find a reference to your work on the
www.opensource.org website. Did I look in the wrong spot? Or is your code not
yet approved as "open source"? Some clarification on the status would be
helpful, as others might also be working on similar open-source proposals.

Thanks for stepping up and letting the industry know about your work!

-- Frank

---

From: Eric Busboom <[email-masked]>
Date: Wed, 02 Jun 1999 15:15:46 -0700

Before offering criticisms, I must commend everyone who developed iTIP and the Core Object Specification. The structure has been very logical and very easy to implement. Converting the RFCs into code has been very direct -- I wish every protocol I had implemented had been so well designed. My comments really address only the finishing touches on an otherwise excellent work. 

At 02:15 PM 6/2/99 , Frank_Dawson/CAM/[email-masked] wrote:

>The primary focus to me is the protocols and formats, not the APIs. 

I agree whole-heartedly, in both philosophy and practice. Currently, I am working on a C API, but the plans call for implementations in a variety of languages, so it would be foolish to want a protocol that was specific to an API or language. 

Here are my main points: 

	People will have the most (only?) contact with the iCAL protocols either by creating an
	API for the protocols or by using an API.  

	If an API cannot mirror the structure of the protocol, the API will be difficult to 
	create, understand and use. 

	Therefore, aspects of the protocol that make it difficult to implement become 
	usability problems for the only people who have direct contact with the protocol. 

I don't suggest any changes that affect the capabilities of the protocol, but I think that the protocol should be easy to implement in a direct way, and that any aspect that makes it difficult to implement should be changed if the change is:
	
	is relatively easy
	does not impact functionality
	does not make the protocol unreadable

So, I want to point out places that I think the protocol is difficult to use, from a programmer's perspective, because programmers are the primary direct user of the protocols. Very few people are going to telnet to a CAP server to manipulate their calendars -- they are going to use an API. If an aspect of the protocol makes every API difficult to use, that aspect should be changed. 

The "multiple types for properties" comment indicates a place where I think that any API in a strong typed language will be awkward to use, simply because it requires that "get" functions will return one of several different types. To remedy this, I suggest that we find a way to combine the several types into a single type, where practical and possible. 

( In your response, you noted several instances where these combinations are not practical or possible. Please consider the other more plausible cases. ) 

>helpful, as others might also be working on similar open-source proposals.

From http://www.opensource.org/products.html

>If you use the MIT license, or GPL, or Artistic License, or BSD license, or 
>any of the other example licenses listed in OSD clause 10. then your software is Open Source >and you may use the Open Source mark without asking.

Libical is licensed under the MPL, which is listed in OSD clause 10.

eric.