[Ietf-caldav] Going from browser to application

[Lisa Dusseault]

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

On May 17, 2006, at 11:11 AM, Wilfredo Sánchez Vega wrote:

> Julian-
>
>   I'm leaning with Mike at the moment, but maybe I don't understand  
> how the davmount scheme would help me here.  Specifically, I don't  
> know what the client/server exchange would look like given that we  
> aren't starting at a hypertext document as in the section 4 example  
> in the mount draft.  In the calendar case, you start with iCalendar  
> text, not HTML:
>
>  1- Client retrieves representation of CalDAV resource "/calendars/ 
> wsanchez/par-tay.ics":
>
> 	GET /user42/inbox/ HTTP/1.1
> 	Host: www.example.com
>
>  2- Server returns representation.
>
> 	HTTP/1.1 200 OK
> 	Content-Type: text/iCalendar
> 	Content-Length: xxx
> 	
> 	BEGIN:VCALENDAR
> 	..
> 	END:VCALENDAR
>
>  3- What happens here?
>
>   There is no link for the use to click on here.  In your example,  
> the server sent back some HTML.  The user is shows that document,  
> and has to then click on a link to make the desired action happen.
>
>   In our case, the browser got some iCalendar data, and there's  
> really no good place for the server to shove in a link, nor would  
> it really want to if it could.
>
>   Now as an alternate example, the client might start with the  
> calendar collection resource, rather than with one of the iCalendar  
> resources contained in it.  The server is free to send back any  
> data it wants to on a GET response in that case, so it could send  
> back HTML.  But a server might want to instead send back monolithic  
> iCalendar data for the entire calendar so that existing calendar  
> clients (eg. Apple's iCal) can use that URL.
>
>   So that leaves a server having to choose between supporting a  
> legacy calendar client, or supporting a generic (HTML-centric) web  
> browser.  Or doing a bunch of user-agent matching, because iCal  
> wasn't smart enough to send an Accept: header and web browsers  
> don't send useful Accept: headers.
>
>   Am I misunderstanding how the mount scheme would fit in here?
>
> 	-wsv
>
> _______________________________________________
> Ietf-caldav mailing list -- Ietf-caldav at osafoundation.org
> See http://ietf.webdav.org/caldav/ for more CalDAV resources
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/ietf-caldav/attachments/20060517/24c49f52/attachment.html