[Cosmo-dev] Cosmo and Scooby URLs
Mimi Yin
mimi at osafoundation.org
Thu Jun 15 15:10:32 PDT 2006
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 priorities.
Mimi
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/
> bobby/HomeCalendar?ticket=87568hKHJHGJT867gJ.
>
>> + 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.
>>
>> 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
>>
>> _______________________________________________
>> cosmo-dev mailing list
>> cosmo-dev at lists.osafoundation.org
>> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev
>
> _______________________________________________
> 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