Cross-Platform Calendar Conflict and Resolution Engine

Cross-Platform Calendar Conflict and Resolution Engine There are two component types in the server. The first component is a “connector” which, given a users’s calendar credentials accesses (for reading and writing) a CalDAV (or other API) on the target calendars. There are two “types” of connectors. The first type of connector is server-resident and queries iCloud calendars and Google Calendars (and potentially other network resident calendars). These will likely be using calDAV or Google API (whatever Google is recommending these days to access Calendar). The second type of connector is client-based used to collect data from machine resident calendars such as Outlook for Windows, Outlook for Mac, iCal, etc. These will need to be built as code for the specific machine and possibly OS or application version. Connector credentials (username and password) will for each calendar to be connected to will be stored in a MySQL database. Each connector should have a test(un, pw) method that verifies that the username and password is correct and determines any limitations to the functions available to it (e.g. read-only, etc) and delivers a return code based on the result. The second component will identify any scheduling conflicts between one or more calendars for a given time and date. Example, if given an event in calendar 1 from 7pm to 9pm (or 19:00 – 21:00) on 15 July 2013 the application will search one or more other calendars for any events which conflict with it). The conflict detection component (component two) will work from stored calendar data (in the MySQL db) that had previously been retrieved from calendars if a calendar is not online and available, but each time the calendar is available on a query the database will be updated with current information. If a conflict is detected the conflict detection component will alert the user AND it will call extendible methods to propose alternative scheduling for the new event that would not conflict. These extendible methods will be limited initially, but will be easily added to the application in the future. We would see them as methods that would be compiled into future versions. The conflict resolution component will have the ability to use the calendar connectors to update/change calendars when an event time is changed (either by selecting one of the proposed alternative times or to a specifically given time/date. The server programs (server resident connectors and schedule conflict resolution component) will run on Linux and should be written in a c variant (c, c++, etc). The connectors shall be separate programs so that the core (second component/schedule conflict resolution component) can employ whichever one it needs for a given calendar. The client resident connectors will be written in some variant of c compiled for the target machine (mac OS/X, Windows, etc). The client resident connectors will have only what GUI is required to install and configure the application and test connectivity (to the local calendar and to the server). The server resident connectors and schedule conflict resolution component will be command line applications or services that have the ability to report to syslog and varying levels depending on configuration file debug settings. Please respond with your experience in accessing remote and local calendars as well as your experience in each of the platforms involved. Please give some information about how you’d approach the applications and any questions you have about it.