[Cosmo-dev] Cosmo and Scooby URLs
mikeal at osafoundation.org
Thu Jun 15 14:01:33 PDT 2006
I think the wording of "Scooby as the interface for Cosmo." conflicts
with the objective of cosmo being a multi format, multi client
supporting sharing server.
I view scooby as a rich webclient to cosmo, exposing some of the best
features of cosmo and providing a chandler like web experience . But
the wording ""Scooby as the interface for Cosmo." implies that it's
the defacto interface to cosmo. If cosmo is to advertise support for
clients outside of scooby/chandler it needs it's own web interface to
display that, and for users to interface directly with cosmo.
What I like about Bobby's proposal is that the url implies it's own
use. A far more confusing situation exposes itself if we create
tickets with crazy hashes at the end that are swapped around over
various communication mediums (email, IM) and nothing about those
urls implies their use. One ticket could be read/write for chandler,
another for atom feeds, another ticket is for users to get write
access in scooby to a calendar. Bobby's proposal is simple and
elegant and the urls are self explanatory.
More in line below.
On Jun 15, 2006, at 9:48 AM, Sheila Mooney wrote:
> 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 share.
> + 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...
How about this;
If the intention is for people to click on an URL and open scooby,
send them http://cosmo-demo.osaf.org/webclient/bobby/HomeCalendar .
But if the intention is that they view the URL in a CalDAV client
send them caldav://cosmo-demo.osaf.org/dav/bobby/HomeCalendar, this
way their rich client (Firefox, Mail.app) can be configured to send
off this calendar to whatever external application it believe handles
caldav (Evolution, Chandler). If an url, like a collection containing
items that aren't just calendar events is intended for Chandler or
some other client that supports all the features of our new sharing
format send something new like (chandler://cosmo-demo.osaf.org/
sharing/bobby/HomeCalendar, This violates some spec somewhere I'm
sure.... probably a few specs??).
My point is just that having one URL mean many things across many
clients introduces more problems than it solves as I said above, and
instead I think a better solution is to have the urls imply their
> + For group C (users with no account), they can view or edit a
> calendar simply without having an account on Cosmo.
This could be done with a read ticket _for scooby_. So the ticket
would be something like href="http://cosmo-demo.osaf.org/webclient/
> + 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.
So a read/write ticket _for scooby_.
> + 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.
I think the scooby webclient should display the url for viewing
Chandler, so if you send around universally web readable scooby urls,
scooby has a link to view the same calendar in Chandler. And example
we be how Google Calendar displays a link to view in iCal.
> + If you are using some other type of CALDAV client, there might be
> an option to say, create a CALDAV URL.
Why do we need to create it? We could display the url for view in
CalDAV client the same way we show the url for Chandler, and it's
always there because the sharing server always knows how to represent
the calendar events to CalDAV.
> 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
>> <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
>>>> 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
> cosmo-dev mailing list
> cosmo-dev at lists.osafoundation.org
More information about the cosmo-dev