1
0
mirror of https://github.com/etesync/android synced 2024-11-29 19:38:23 +00:00
etesync-android/libs/ical4j-1.0.5/etc/TODO
rfc2822 3729951b52 Calendar improvements
* recurring events
* classification
* status
* attendees
* ical4j 1.0.4 -> 1.0.5
* remove biweekly (replaced by ical4j)
2013-10-05 10:59:19 +02:00

100 lines
3.8 KiB
Plaintext

To-do List:
==========
- Add "relaxed" option for parsing dates (ie. attempt both date and date-time regardless of value type)
- inspect date-based properties and default local time where TZID parameter
is identified
- Add note regarding Outlook requiring Method=Publish and UIDs for each event for correct parsing.
- Allow for extra whitespace between all content lines in the parser.
- investigate use of commons-lang for equals/hashcode implementations.
- add validation to ensure that date-time instances are not used where only date
instances are applicable..
- investigate use of alternative Base64 implementation (michael grev?)
- Timezone processing and validation as follows:
* In validation, ensure any referenced VTimeZones (TzId parameter) are included in the
VCalendar on output.
* possibly automate VTimeZone inclusion by examining all date/date-time-based properties
for timezone-specific instances.
- Provide the option for automatically adding referenced VTimeZones to calendar
===========
RFC 2446:
===========
* net.fortuna.ical4j.transform
* Transformer
- Calendar wrap(Component component); // wraps the specified component in a calendar
- Calendar transform(Component component); // wraps a component in a calendar and transforms
- abstract Calendar transform(Calendar calendar); // abstract calendar transform
* PublishTransformer (Organizer)
- Calendar transform(Calendar calendar); // publish/republish a calendar
* RequestTransformer (Organizer | Attendee)
- Calendar transform(Calendar calendar); // creates a request for reply to a calendar
* ReplyTransformer (Attendee)
- Calendar transform(Calendar calendar); // creates a reply to a request for this calendar
* AddTransformer (Organizer)
- Calendar transform(Calendar calendar); // add a published calendar
* CancelTransformer (Organizer)
- Calendar transform(Calendar calendar); // cancel a published calendar
* RefreshTransformer (Attendee)
- Calendar transform(Calendar calendar); // refresh a published calendar
* CounterTransformer (Attendee)
- Calendar transform(Calendar calendar); // counter a published calendar
* DeclineCounterTransformer (Organizer)
- Calendar transform(Calendar calendar); // decline a counter to a published calendar
==========
RFC2447:
==========
* When implementing the creation of a MIME message incorporate a human-readable text summary in case
iCalendar is not supported by the recipient. Add Calendar/Component formatting into human-readable
text/html.
==============================
Questions for calconnect.org
==============================
* When implementing a CUA there are occasional incompatibilities discovered with alternate implementations. Would it
be possible for calconnect members to maintain a compatibility matrix in areas that are either ambiguous or not
clearly defined by RFC2445?
* Timezone support for iCalendar depends heavily on identical timezone definitions used across all CUAs. VTIMEZONE
objects may be included in iCalendar files, however this is not mandatory. Would it be possible for calconnect to
maintain a repository of VTIMEZONE objects accessible to all CUAs (similar to those provided by libical)?
* With the complexity of the iCalendar specifications, it is more than likely that each CUA implementation does not
implement the entire specification (correctly). Could calconnect provide a common set of test cases (possibly defined
in a use-case format) that each CUA must pass to be a "certified" implementation of iCalendar?