I listed some needings in previous post. In this post i focus on number 4.
`4.should have support on a common protocol `
For delivering anything to anyone,choosing a delivery way that everybody knows is the best option. So, if there is a common way exists and well defined. It will be perfect. After some research I found that there is actually a protocol specified for calendaring which is called CalDAV. This protocol is an extention to protocol called WebDAV. WebDAV is basically delivering resources via HTTP protocol. The queries for searching, retrieving or sending resources to webdav service are basic XML elements. After some digging i found an implentation for CalDAV which is called DaviCAL. I establish an enviroment for testing and understanding how caldav works. The enviroment includes;
- Virtual Ubuntu server with http service (DaviCAL application installed)
- Fedora 27 (its mail client Evolution supports CalDAV protocol)
- iPhone 4S (its operation system supports CalDAV protocol)
After setting all things up, i create an user on DaviCAL and start unencrypted session to listen network packages via `tcpdump` command. Result are in *.pcap format(which you can open via WireShark);
And i start to exemine what was transferin on theese packages. I found out that there bunch of XML data and specific XML tags. But later i saw this:
The data in clear text is in the format like this(not same data appearance same):
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//ABC Corporation//NONSGML My Product//EN
BEGIN:VTODO
DTSTAMP:19980130T134500Z
SEQUENCE:2
UID:uid4@example.com
ORGANIZER:mailto:unclesam@example.com
ATTENDEE;PARTSTAT=ACCEPTED:mailto:jqpublic@example.com
DUE:19980415T000000
After some lookup i get this the iCal data which is the most common data format to delivering calendar information from differen sources. iCal Data Refference. So, the iCal data is delivering with help of WebDAV protocol in the CalDAV protocol. iCal data repesent 3 base things: component, properties and parameters. Components are the element we are familliar; Calendar, Event, Todo, Journal and Alarm. Properties are the every line of the iCal data and parameters can give special properties to iCal properties.
BEGIN:VCALENDAR [CALENDAR STARTS]
VERSION:2.0
PRODID:-//ABC Corporation//NONSGML My Product//EN
BEGIN:VTODO [TODO START - THERE IS A TODO IN THE CALENDAR]
DTSTAMP:19980130T134500Z
SEQUENCE:2
UID:uid4@example.com
ORGANIZER:mailto:unclesam@example.com
ATTENDEE;PARTSTAT=ACCEPTED:mailto:jqpublic@example.com [THERE IS AN ATTENDEE(mail address:qpublic@example.com
WHO IS ON THIS TODO AND WITH PARAMETER PARTSTAT S/HE
DECLARES THAT ACCEPT THE TOTO]
DUE:19980415T000000
STATUS:NEEDS-ACTION
SUMMARY:Submit Income Taxes
BEGIN:VALARM
ACTION:AUDIO
TRIGGER:19980403T120000Z
ATTACH;FMTTYPE=audio/basic:http://example.com/pub/audio-
files/ssbanner.aud
REPEAT:4
DURATION:PT1H
END:VALARM
END:VTODO [TODO END]
END:VCALENDAR [CALENDAR ENS]
Despite been common and extendable, iCal data format looks like can covertable to the another data format which is also common. JSON. An calendar has an event component can be represent in json;
{
"@type":"Calendar",
"components":[
{
"@type":"Event",
"components":[
{
"@type":"Alarm",
"creationDate":1520790033000
}
],
"properties":[
{
"@type":"Attach",
"id":1,
"name":null,
"value":"A FILE",
"parameters":[
{
"@type":"Encoding",
"id":1,
"name":null,
"value":"UTF-8"
}
]
},
{
"@type":"Dtstamp",
"id":2,
"name":null,
"value":"160620018092822 UTC+3",
"parameters":[
]
}
],
"creationDate":1520790033000
}
]
}
So, it is clear that theese to data formats(iCal and JSON) can convert each other easly and as detaily shown in RFC 5545 that iCal data format is more then enogh for determining calendar, events and todos. To sum up, while collecting calendar data having iCal data as main reference has no harm at all.
Comments