Re: [Ietf-caldav] Going from browser to application

["Mike Shaver" <[e-mail]>]

On 5/17/06, Julian Reschke <[e-mail]> wrote:
> Mike Shaver schrieb:
> >
> > Content-disposition: attachment?
> >
> > I'm not exactly sure why a browser can't be the thing that handles it
> > correctly, but C-d:a is how servers are supposed to indicate "probably
> > want the user to pick where this goes", by my recollection.
>
> Yep, but I'm not sure how this helps here. Sending that header will
> cause user agents to display a download dialog. What we're looking for
> is something that triggers automatic invocation of a non-browser
> application for a specific URL.

It will cause user agents to display a "how do I handle this?" dialog,
which includes selection of a helper app in most (all?) browsers that
support C-d:a.  And if you want another app to handle some content, we
call that a helper app. :)

> > I don't like MIME type for this, since as you say it's the same data
> > (in the same format), which seems to me to have the same undesirable
> > characteristics as using a different scheme for data that comes over
> > HTTP.
>
> Depends on how you use the MIME type. The one I defined in
> <http://greenbytes.de/tech/webdav/draft-reschke-webdav-mount-04.html> is
> used to transport information about how to "mount" an HTTP URL in the
> system's WebDAV client. That information includes a base URL (mount
> target), a child collection to be displayed (which may be below the
> mount target), plus additional information (such as account).

That doesn't sound like the use case that Lisa was describing:

> > On 5/16/06, Lisa Dusseault <[e-mail]> wrote:
> >> When the same data can be viewed either as a Web page or as data to
> >> be consumed by an application, there's a general issue over how to
> >> get the user from one to the other.  Typically it's how you get the
> >> user from browser to specialized application.

You're not talking about the same data being viewed as a web page,
you're talking about sending a different kind of data, it seems.  Like
sending a playlist rather than an audio file, perhaps.

(If a browser has WebDAV manipulation capability, which doesn't seem
entirely implausible to me, we're back in the same situation.
Content-disposition-style hints would be more appropriate here,
because you really are talking about how the content should be
dispatched, not what the structure or format or "type" of the content
that you're sending.

Mike