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

[Julian Reschke <[e-mail]>]

Mike Shaver schrieb:
> 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. :)

But to make this work, the content would need to contain the information 
that that helper application needs to do it's work. That is, minimally 
the URL (*). In general, HTML content won't contain that, in even if it 
would (extension, or something like a base attribute), the helper app 
would then need to parse the HTML, right? Somehow it seems more 
straightforward to me to dump all information that is needed into a 
specific XML format, and let the helper app extract all the information 
it needs.

BTW: this will make the information bookmarkable, and it also allows 
storing the information in a local file, and to active it without any 
browser interaction (so you can store something like "Mount my documents 
on portal.davmount" and just double-click it to active it).

(*) Note that this is one of the reasons why the "feed" scheme people 
have been talking about wouldn't be needed with Atom, as each feed 
contains a "self" link.

>> > 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:

Well, it's the use case I had to solve, and which I documented in that 
Internet Draft (which in turn triggered Lisa's mail).

>> > 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.

Hm. If the use case I mentioned above can be implemented using 
Content-Disposition in a way that it works in all current browsers, I'm 
interested. As far as I can tell, I'll still need a MIME type to 
dispatch to a specific helper application, though (in which case I'm not 
sure what the benefit is over the solution I already have).

Best regards, Julian