|
Frank The beef is that it takes two objects. In earlier correspondence you have pointed out that sometimes two objects can be of advantage. You have also pointed out that the database generating these two objects need not be formed as the objects it is generating, i.e. there could be one database entry generating two or more objects. I have no "beef" with that. Remember this is just a simple example. About the most simple example of a polyphonic calendar object I could think of. As objects grow in complexity, it is my belief that we will reach a point, whereas a strew of related objects will become "bulky". Polyphonic calendar objects representing multiple instances, utilizing the mechanism of conditional qualifiers zzzzzzz:-) will be streamlined for thin client applications. The need to generate a new calendar object for every event instance other than those generated by recurring times, is not optimal to multi-instance calendars. At least, that is what I believe. In January, Johan Hjelm of the WAP Forum will be organizing a live demonstration with SKiCal over WAP, where we will be checking transfer times for some rather complicated calendar objects. At that public event, I will hope to prove what I claim. If I am wrong - I will be the last one to admit it:-) Greg ---------- From: Frank_Dawson@lotus.com To: "Greg FitzPatrick" <gf@medianet.org> Cc: ietf-calendar@imc.org Subject: RE: multiple calendars-multiple instances Date: ons 3 nov 1999 19.37 Greg: One slide is a little misleading. It says: "This is also a duophonic Cal (sic?) object. It describes two "identifically descripted (sic?)" WHATS, occuring at the exact same WHEN in two different WHERES. For example, if Ronald McDonald was to make an appearance in two restaurants at the same time. This can not be described in iCal without using the mechanism of related objects." The implication is that iCalendar can't do this and is deficient. The use of RELATED-TO property is not an enhancement or add-on to iCalendar. It is an integral part. Hence, iCalendar CAN SUPPORT THIS topology. Where is the beef? -- Frank |