[Cosmo-dev] Cosmo and Scooby URLs
sheila at osafoundation.org
Thu Jun 15 09:48:46 PDT 2006
I just want to expand on the problem that John outlined by providing
some more context on what we are trying to accomplish at a user
perspective. Keep in mind these are product requirements and it's up
to engineering to determine the best technical solution ie:
repurposing the existing tickets or have Chandler generate some new
type of URL. As John mentioned, you publish calendars in Chandler,
the URLs get generated and you can send those to others to subscribe
to. Currently in Chandler you need to cut and paste the URLs in order
to subscribe. You could receive this in an email in Chandler or some
other email client.
Although we are accustomed to the copy/paste way of subscribing in
Chandler, most users will want to simply click on this URL and have
something happen. There are several scenarios...
+ A. I am a Chandler user, I want to subscribe to this share and have
it appear in my sidebar in Chandler.
+ B. I am a Scooby user with a Cosmo account and I want to view this
+ C. I am neither but I want to be able to view or edit (depending on
the url) info in this share.
+ D. I am some other type of user that wants to view this calendar in
some other CALDAV client.
What we envision happening is that when you receive a URLs and click
on it, Scooby pops up to show you the read-only or read-write view of
this calendar. In a way, you can think of it as a preview. From,
there you have a series of options...
+ For group C (users with no account), they can view or edit a
calendar simply without having an account on Cosmo.
+ If you are an existing Scooby user, you will have some kind of
option to login and "subscribe" to this share. Subscribing in this
sense, means that the next time you log into Scooby, you this share
will appear in that drop-down of all the calendars you can view.
+ If you are a Chandler user, you have an option to subscribe in
Chandler which probably automatically launches the app, subscribes
and shows the collection in your sidebar. Users would not have the
same (cut and paste) subscribe workflow that they do today. You don't
always know what you are receiving and this will allow you to preview
the collection before subscribing.
+ If you are using some other type of CALDAV client, there might be
an option to say, create a CALDAV URL.
Mimi and I really see Scooby as the interface for Cosmo. When you
click on something, the Scooby browser is what you get and you will
have a series of options depending on what action you want to
perform. Instead of the human readable web page Bobby suggests, your
entry point to the ecosystem is Scooby.
On Jun 14, 2006, at 4:35 PM, Bobby Rullo wrote:
> I think the problem that you are trying to solve, John, is
> legitimate - namely that of not having the user be confused by a
> deluge of sharing URLs that are used for different purposes - i.e.
> "Use this url to access my calendar in Scooby, this URL to use in
> iCal and this one in Chandler, and this one in Evolution"
> But I don't think overriding DAV behavior (even if the spec does
> leave it undefined) is the right solution, for the reasons
> mentioned by Brian as well as some vague queasiness about it just
> not feeling right architecturally. It's sort of like doing a SQL
> select statement on your RDBMS and getting back a PDF report or
> something. Not quite that wrong, but along those lines.
> The source of confusion here is that URL's are sort of unique in
> that they locate resources that humans consume directly sometimes
> (html pages), and sometimes locate resource that are only machine
> readable (XML, icalendar resources, etc.) We see a URL and we want
> to click it or paste it in our browser.
> Todd and I were hashing this out over IRC and noticed that the RSS
> world solves this problem by having "autodiscoverable" links within
> a normal (that is, human readable) web page. Why not do something
> similar with cosmo? Have one uri space called "sharing" (eg. the
> sharing url might be "http://cosmo-demo.osaf.org/sharing/bobby/
> HomeCalendar") for instance that returns an human-readable html
> page with verbiage like "To view your calendar in scooby, click
> here. Copy this link for RSS readers. Copy this link for ATOM
> readers. Copy this link for CalDAV clients like Evolution and
> Chandler" for humans and for savvy clients who do autodiscovery
> have links embedded in the page like:
> <link rel="alternate" type="application/atom+xml" title="Home
> Calendar (Atom 0.3)" href="http://cosmo-demo.osaf.org/atom/bobby/
> HomeCalendar" />
> <link rel="alternate" type="application/rss+xml" title="Home
> Calendar (RSS)" href="http://cosmo-demo.osaf.org/rss/bobby/
> HomeCalendar" />
> <link rel="alternate" type="application/caldav" title="Home
> Calendar (CalDAV)" href="http://cosmo-demo.osaf.org/dav/bobby/
> HomeCalendar" />
> <link rel="alternate" type="application/webcal" title="Home
> Calendar (Webcal)" href="http://cosmo-demo.osaf.org/webcal/bobby/
> HomeCalendar" />
> Note that I don't believe anyone's defined a way to do
> autodiscovery for CalDAV yet, so we'd have to take the lead here.
> The nice things here are that
> a) You can make Chandler (and Scooby) smart enough to autodiscover
> the CalDAV link (or whatever protocol we go with for Chandler in
> the end) or consume a CalDAV (or atom or XXX) url directly, and
> other clients already know how to autodiscover rss, atom etc.
> b) You have one place to show off all of Cosmo's conduits!
> c) You're not clobbering CalDAV or anything.
> (props to Todd for working through this with me)
> On Jun 14, 2006, at 2:31 PM, Brian Moseley wrote:
>> On 6/14/06, John Townsend <johntownsend at mac.com> wrote:
>>> One thought on this was to have a well-known URL in each collection
>>> that would provide
>>> the same behavior. Something like this:
>>> GET /cosmo/home/towns/Work/Work.ics
>>> That would return an iCalendar format file for the entire collection
>>> and Cosmo
>>> would do that dynamically.
>>> Would that work for iCal's needs?
>> yes, but i have two problems with it:
>> 1) it introduces a bogus url that doesn't actually represent a
>> resource. i'd rather use a query parameter (or even better a custom
>> header, but this wouldn't work with existing clients)
>> 2) it defeats the purpose of having a single url that works for all
>> dav and caldav clients. chandler and scooby would have to make sure
>> the user knew to tell their chandler, scooby, sunbird/caldav, et al
>> using friends about url A and their ical and sunbird/webcal using
>> friends about url B. to me that is *way* more confusing than having
>> separate "data" and "web calendar" urls.
> cosmo-dev mailing list
> cosmo-dev at lists.osafoundation.org
More information about the cosmo-dev