Re: Re: Proposal of new package Services_ICAL

From: Date: Sat, 21 Jan 2006 17:44:15 +0000
Subject: Re: Re: Proposal of new package Services_ICAL
References: 1 2 3 4  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-41023@lists.php.net to get a copy of this message
Dan, My concerns are more from the reusability standpoint: - How to store the calendar (File, DB, LDAP...), - Access control (Basic Auth, Challenge-Response...), - Update/retrieval methods to the calendar (XML-RPC, SOAP, ReST, ...) - etc... I don't know if there is an existing official or de facto standard for all this, but that would be the way to make your case. -Philippe Dan Rossi wrote: > > On 21/01/2006, at 9:05 AM, Arnaud Limbourg wrote: > >>> No offense, but I think this would be better suited as a mere a example >>> for the File_IMC package. There are too many shortcomings as-is. The >>> term "subscribe" is also missleading, since there are no notifications >>> sent on publish. >> >> Sigh, that is too bad, I had all those crazy ideas ... >> >> Arnaud. >> > > Umm, this is a draft code done in less than a day. Ok its not really an > example for File_IMC in my opinion, this code also works for Mozilla > Sunbird aswell as Ical. File_IMC doesnt seem to easily build back > vCalendar markup say from the db, ive added a few extra methods to call > a callback method for processing the array and adding to the db. My only > issue is that there is no way of identifying uniquely the published > calendar for now. When you say no notifications , do you mean to the end > user ? As it doesnt seem there can be unless they are using say CalDav > which seems to transfer in xml. The notification is pretty much instant, > in ICal it creates the subscribed Calendar is when refreshing gets the > updates from the published Calendar.

« previous php.pear.dev (#41023) next »