Re: Re: Proposal of new package Services_ICAL
| From: | Philippe Jausions | 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.