[Cosmo-dev] Cosmo and Scooby URLs

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

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

Sheila

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.
>
> Thoughts?
> (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
> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev



More information about the cosmo-dev mailing list