[Cosmo-dev] Cosmo and Scooby URLs
mikeal at osafoundation.org
Thu Jun 15 15:46:03 PDT 2006
Right now we have one way tight coupling between the cosmo and scooby
projects. Scooby _requires_ cosmo, but Cosmo doesn't require scooby.
Scooby has not plans of interop with other clients, and Cosmo does.
That said, it is important that we prioritize the interaction between
Scooby and Cosmo over our interop with other clients, but if we
tightly couple Cosmo to Scooby we sacrifice much of our ability, even
down the line, to meet our long term goal of interop with other clients.
I think there is a technical solution to the "one url to rule them
all" scenario that only requires the coupling of cosmo and scooby
that we already have.
If the objective is to give one URL to Chandler and non-Chandler
(Scooby) users we should just give them the url to read or read/write
the calendar in Scooby. Then Scooby can include logic to hand that
request off directly to cosmo if it determines that the request came
from chandler ( we could do this based on 'User-Agent' header, or the
'Accept' header, etc ).
This doesn't interfere with Bobby's proposal below which is a very
good step in our supporting multiple formats, and since Scooby
doesn't need to handle requests in a DAV or any other sharing spec
compliant way we aren't limiting any further Scooby functionality
like we would be if we had cosmo directing the "one url" to scooby.
Cosmo could also still have it's own interface, and you wouldn't be
accessing it unless you knew about it :)
On Jun 15, 2006, at 3:10 PM, Mimi Yin wrote:
> Yes, I think a better characterization of what Sheila was trying to
> say would be: Scooby is 'an' interface to Cosmo for the set of use
> cases we need to support for Beta.
> However, if for whatever reason, in order to get to Beta, Scooby
> needs to be 'the' interface to Cosmo in the short-term, then so be
> it. We've all decided (based on the internal product prioritization
> exercise) that supporting ecosystem workflows is more important
> than meeting interoperability standards.
> That being said, from the product perspective, we're trying to pin
> down user experience requirements. We're hoping that Engineering
> will come up with the best technical solution given our goals and
> On Jun 15, 2006, at 2:01 PM, Mikeal Rogers wrote:
>> 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 intended medium.
>>> + 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 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
>>>>>> 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
>>>>> header, but this wouldn't work with existing clients)
>>>>> 2) it defeats the purpose of having a single url that works for
>>>>> dav and caldav clients. chandler and scooby would have to make
>>>>> 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
>>>>> 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
>> 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