[Cosmo-dev] Cosmo and Scooby URLs

[Brian Moseley]

On 6/15/06, Sheila Mooney <sheila at osafoundation.org> wrote:

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

there is no way for cosmo to distinguish between these two cases,
since a sharing url as currently implemented has no identifying user
information in it.

i can imagine two ways to handle the issue:

1) if there's a ticket in the url, behave as per the first case above

2) if there's no ticket, show a login page and, if the user
successfully logs in, show him the calendar

of course this doesn't address the problem of having the server figure
out to use scooby to handle the request rather than using dav. bobby's
suggestion, with which i agree, is for cosmo to support two different
urls: a dav one and a scooby one. either could contain a ticket (with
either read, read-write, or freebusy privilege) or no ticket.

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

again, there are two options for making this work:

1) use a url with a scheme (eg
<chandlershare://cosmo-demo:8080/cosmo/home/bcm/calendar/>) that is
mapped at the os or browser level to the chandler app, thus opening
the app when the link is clicked. this is a misuse of url schemes, and
i will argue strongly against it.

2) have a url whose response is of a media type (eg
application/xml+cosmo-sharing that is mapped at the os or browser
level to chandler. this is my preferred solution. note that this again
either requires content negotiation by the server (by examining the
http accept header, for instance), or by having a special url just for
this media type.

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

i must strongly disagree. i understand that osaf has decided that the
ecosystem is priority one, but let's not throw out the baby with the
bathwater. we can accomplish sharing without compromising our
principles.