[Ietf-caldav] Going from browser to application

[Wilfredo Sánchez Vega]

   Got it, OK.  I misunderstood you as meaning to solve the issue for  
existing resources.  New new dispatching resource as the URI you link  
to may be useful, I agree.

	-wsv


On May 17, 2006, at 5:20 PM, Lisa Dusseault wrote:

>
> Wilfredo,
>
> I don't quite make sense of your scenario as an application of the  
> davmount scheme.   What I meant to convey, was that calendars might  
> also usefully be advertised in Web pages and other content that  
> contains links.  That's where the HTML comes in.
>
>  If I were to follow Julian's example for calendaring but start  
> from scratch (leaving aside the alternative of actually extending  
> davmount), here's what I might propose, combining workflow and  
> examples with mechanics:
>
> 1. An HTTP  URL for a "calendar info file" would appear online on  
> my Web page (or in an email, or in a Web page listing several  
> peoples' calendars).
>
> 	E.g. <a href="http://example.com/users/lisa/calendars/work- 
> calendar-info.xml">My Calendar</a>
>
> 2. The "calendar info file" would be a *new* resource beyond those  
> already described in CalDAV.  It might be a sibling resource of a  
> CalDAV calendar collection (though it could live anywhere, even a  
> different server modulo security considerations).  It would have a  
> MIME type something like application/caldav-calendar+xml (assuming  
> XML) so that the browser would be caused to dispatch the whole file  
> to an application registered as handling that MIME type.
>
> 3.  Inside it would be at a minimum, the URL of the calendar that  
> was advertised -- because when this file is downloaded by a  
> browser, the browser sends the file to a calendar application that  
> doesn't know the URL where the file came from!  We might also think  
> of additional helpful information that could go in that file, e.g.  
> even before the calendar application does an OPTIONS or a PROPFIND  
> on the href given, the calendar application might want to prompt  
> the user depending on the possibilities:
>
> 	 "Opening: calendar for 'Lisa Dusseault'.  Do you want to view,  
> subscribe or import?"
>
> thus the insides of the file might look like this (omitting  
> namespaces and other niceties, and inventing capabilities out of  
> thin air):
> 	<calendar-info>
> 		<for>Lisa Dusseault</for>
> 		<capabilities>
> 			<caldav><href>http://example.com/users/lisa/calendars/work/</ 
> href></caldav>
> 			<atom-calendar-feed><href>http://example.com/users/lisa/ 
> calendars/work.atom</href></atom-calendar-feed>
> 			<full-icalendar><href>http://example.com/users/lisa/calendars/ 
> work.ics</href></full-icalendar>
> 		</capabilities>
>  	</calendar-info>
>
> Lisa