Re: Re: Proposal of new package Services_ICAL

The idea for this one is , well i was using a basic callback, but now looking into Event_Dispatcher which can be setup to call an event function or class method to handle adding to the database, i dont think it should really be handled in this, this then gives the flexibility. Main methods saveToFile or saveToDB are pretty straight forward, however maybe they should be drivers if i was to handle adding to the db internally ? As for the update retrieval methods, as ive said before when a client like ICal subscribes you set the interval to refresh and reload the calendar, there is no such protocol for them to be notified from my understanding, but maybe just maybe if using the CalDav protocol. But then again maybe the data could then be retrieved using xml protocol for syndication, but i think that goes outside the scope of this ?? On 22/01/2006, at 4:44 AM, Philippe Jausions wrote:

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.

-- PEAR Development Mailing List (http://pear.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php