[Ietf-caldav] Going from browser to application

[Kervin L. Pierre]

Hello,

Have we or should we rule out...
caldav://example.com/users/lisa/calendars/ ?

Which I guess was how this was handled in the
past.

Best regards,
Kervin


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
> 
> 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 <http://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 
>> <mailto:Ietf-caldav at osafoundation.org>
>> See http://ietf.webdav.org/caldav/ for more CalDAV resources
>> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> 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