From: Jordan M. <jm...@MI...> - 2002-12-02 23:36:23
|
Thanks for your work, it's great. It would be ideal if it didn't require MySQL, though, as this is another layer of configuration, installation, troubleshooting, and backing up that would need to be maintained separately from phpicalendar. Jordan On Sunday, December 1, 2002, at 01:54 AM, Benjamin Levy wrote: > You make a good point here. As far as integrating with iCal directly > I do think working directly with the files may be the way to go in the > future. I think in my project I approached things from a slightly > different point of view, thinking of the server as being remote and > not read/writable by iCal (except for the DAV publishing currently > supported). Given those limitations, this provides a way to enter > events away from your copy of iCal and still receive them later. It's > possible, though, that the annoyances of not being able to edit the > online calendar from iCal will be too much, and make this all not very > useful. > > That said, there are a few other reasons for using a database - namely > I think it's much easier to deal with editing events in a database > than modifying a flat file. Another issue is that many web hosting > providers do not provide anyway to give the web server/php write > permission to your files. In my case, even writing to /tmp is > disabled. As for using MySQL, it just seems to be a typical database > system these days. > > What I've built is sort of an independent thing that knows how to > write ics files. That's the functionality I built first (minus any > user interface). But my goal all along was to integrate with > phpicalendar, and so it can also just build the parsed master array > that phpicalendar uses. > > Ben |