[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: CounterOffer issue
Alec Dunn wrote, in part:
You bring up a good point, and that is that counter offer and tasks
were not included in the draft. The reasoning behind this is that it
is very challenging to get everyone to reach concensus on a particular
draft. The larger the draft, the more contentious points there will be
and the longer it will take to turn the draft into a standard...
<FRD>But, by only focusing on a small part of the problem we face the problem of having to shoe-horn the solution to the larger problem into the more minimal specification. This is an old design problem. If we only focus on a subset of the required calendar components (ie, events) and then only a small set of the required capabilities (ie, request/reply/cancel), then when we focus on the more complete problem we will undoubtably have to overload the semantics we defined for the smaller problem.</FRD>
I'm worried about you and other vendors embracing vCalendar ...
<FRD>There are over 40 vendors working on vCalendar. Is this why Microsoft is worried? This is a substantial constituency that needs to be migrated gracefully to "iCalendar". We definitely can't ignore this design requirement in our deliberations. The Internet history is full of precedents for evolution of technology solutions.</FRD>
On the topic of code for parsing ...
<FRD>About 80% of the folks looking at doing vCalendar have found having a parser/generator VERY useful. It is very straight forward to generate and parse a vCard or vCalendar syntax. The code is not an overhead. It is actually a growing pre-req these days to provide "enabling tools". Microsoft has set a precendent in this area.</FRD>
Also having a
lot of extra-generic parsing code means that users need more memory to
run your products (which is a very bad thing for some customers that
have machines with a very small amount of memory). For example:
DALARM:19960415T235000;PT5M;2;Your Taxes Are Due !!!
is made up of a datetime, a string, a number and a string. This means
I would have to write a special praser specifically for the DALARM
property that would extract out the information I need...
<FRD>There is a tendency here to view all problems as requiring a hammer.</FRD>