[Cosmo-dev] Cosmo and Scooby URLs
mimi at osafoundation.org
Fri Jun 16 15:04:46 PDT 2006
Today, clicking on ticket URLs doesn't launch iCal for me. Are you
saying we would need to spit out a special iCal URL in order to do this?
What about the following scenario:
I receive a sharing invitation, I use Outlook.
I don't know what Apple iCal is.
I don't know what Chandler is.
For that matter, I don't know what Scooby is either.
As far as I'm concerned, I don't use any of those products. I use
Outlook. (Given the reality of the market, this will probably be
I think to myself, ugh, I just don't want to bother.
2 URLS would be easier to understand:
Read only: http://....
Once you're looking at the share on the web, then you can decide what
to do next. Giving users all the options up front is overload.
Furthermore, without previewing the content, how do I even know if
this is something I want to subscribe to in iCal or my RSS reader?
Directing all sharees to a Web UI allows them to preview the share
before subscribing. None of the other solutions address this crucial
step of the workflow.
Also, why should the Sharer care about all of these different URLS?
On Jun 16, 2006, at 2:47 PM, Brian Moseley wrote:
> On 6/16/06, Mimi Yin <mimi at osafoundation.org> wrote:
>> Are you saying that the Sharer should have these options when sharing
>> Send out 4 sets of URLs and then let the Sharee decide which one
>> to use?
> the sharer should certainly be able to access these urls from within
> chandler, perhaps when looking at the properties of a shared
> the sharee ought to have all of these urls in the sharing invitation
> they receive from the sharer. the sharee ought to be able to go to the
> scooby url and see the same links on the scooby page as well.
>> If we generate an iCal URL and someone clicks on it from Apple Mail
>> or Thunderbird, will the URL we generate automatically open up iCal
>> and plop our URL into the Subscribe dialog? That's how URLS generated
>> from iCal work.
> it can, if 1) we use the "webcal" scheme rather than the "http" scheme
> in the url (which i argue we should not do) and/or 2a) the user has
> his browser configured to open resources of type "text/calendar" with
> ical or 2b) the user chooses to open the returned content with ical
> using the application chooser dialog the browser presents when it
> doesn't know anything about "text/calendar".
> i assume that os x has os-level knowledge of "text/calendar" and is
> preconfigured to open ical for those resources.
> same with a "subscribe to feed" url. the user clicks that url in mail
> or thunderbird, the server sends the feed response with a media type
> of "application/xml+atom", and the browser either automatically
> launches the system's feed reader or presents the application chooser
> same with all of the other urls i proposed.
> cosmo-dev mailing list
> cosmo-dev at lists.osafoundation.org
More information about the cosmo-dev