I need PHP scripts that will synchronise Google Calendar with a MySQL database.
The database will have two tables: GoogleEvents and enumSyncStatus. There can be more if it helps you.
enumAddStatus has columns ID (primary key, no auto_increment) and Description (use CHAR, not VARCHAR);
Both tables must contain the following columns: ID INT NOT NULL PRIMARY KEY AUTO_INCREMENT, GID [applicable format] NULL (unique Google Identifier), ...all "relevant" field/parameter/columns that exist for Google Calendar Events*, LocalUpdate TIMESTAMP NULL, SyncLocal TIMESTAMP NULL, SyncRemote TIMESTAMP NULL, Any other columns that are required to make that work properly, SyncStatus TINYINT NOT NULL DEFAULT 0, FOREING KEY (SyncStatus) REFERENCES enumAddStatus(ID)
*Use your common sense. If several are more considerably more work to implement and are not essential, I probably won't require it. In such case, so just ask to make sure that I don't need that column and don't implement it.
LocalUpdate correspond to time a modification were made locally (by me) in the database. SyncLocal is the last time local data were successfully synchronised (uploaded) SyncRemote is the last time newer remote data were successfully synchronised (downloaded)
Whenever a new row is inserted: GID, SyncLocal and SyncRemote are NULL, The event is inserted in Google Calendar, GID is set to the unique Google's identifier for that event and SyncRemote is set to CURRENT_TIMESTAMP;
Whenever an event is modified on Google Calendar (e.g. directly on the website), the data must be updated in the database and SyncRemote set to CURRENT_TIMESTAMP
Whenever the database is updated locally, I will have set LocalUpdate to CURRENT_TIMESTAMP and SyncLocal to NULL. Therefore, when LocalUpdate is set and SyncLocal is NULL, the event on GoogleCalendar must be updated with the local data. When that is done SyncLocal is set to CURRENT_TIMESTAMP.
These TIMESTAMP values are used arbitrarily. They should not be considered as accurate for any type of trigger. Only whether they are NULL can serve a trigger.
Callbacks can obviously be used.
I will use CRON to execute whatever script needs to be run recurrently. I will also call a script as soon as I make a change in the database. It may be the same script that CRON will run or a different one.
You must provide the .sql dump file, php files, specification about where I must enter my account information, url to change for making any callback work, what script to call with CRON and which one to call when I make any change in the database.
I will be responsible of installing the script, loading the database, making the cronjob and any task that require the access to the server.
The deadline is January 15th 2011. However, the deadline for being able to insert new events (no update, no synchronisation and no downloading required) is **Monday December 20th 2010**. Make SURE that **you will be able to complete that part within 4** days because I'm looking forward to have that part completed this week. I'm looking forward to accept a bid by Tuesday. If something wrong happen, I will only be understanding until Monday morning.
If you prefer, I would accept the pay-for-deliverables method instead of pay-for-time.
1) All deliverables will be considered "work made for hire" under U.S. Copyright law. Employer will receive exclusive and complete copyrights to all work purchased. (No GPL, GNU, 3rd party components, etc. unless all copyright ramifications are explained AND AGREED TO by the employer on the site per the worker's Worker Legal Agreement).
2) Complete and fully-functional working program(s) in executable form as well as complete source code of all work done.
3) Deliverables must be in ready-to-run condition, as follows (depending on the nature of the deliverables):
a) For web sites or other server-side deliverables intended to only ever exist in one place in the Employer's environment--Deliverables must be installed by the Worker in ready-to-run condition in the Employer's environment.
b) For all others including desktop software or software the employer intends to distribute: A software installation package that will install the software in ready-to-run condition on the platform(s) specified in this project.
* * *This broadcast message was sent to all bidders on Monday Dec 13, 2010 12:09:00 PM:
Here is a requirement I forgot to mention: I will have to add custom columns to the table and that should not affect the behavior of the system. That means for example that you cannot use "SELECT * FROM..." but need to explicitly enumerate all columns of the table that you want to read. The columns I will add won't necessarily be at the end of the table.
MySQL: [url removed, login to view]