[Cosmo-dev] Cosmo and Scooby URLs
bcm at osafoundation.org
Wed Jun 14 14:25:33 PDT 2006
On 6/14/06, John Townsend <johntownsend at mac.com> wrote:
> - Cosmo has no knowledge of Scooby at this point. To redirect to a
> Scooby URL, we would have to have knowledge of a running Scooby and a
> URL to it. Its possible that someone might want to run Cosmo without
> scooby. We'd have to make sure they would configure the server easily
> to handle that case.
this would be easy to do by, for example, adding a context init param
to cosmo's web.xml or (probably a better choice) adding a property to
cosmo.properties. the param value could be a full url specifying a
remote scooby or a simple context path specifying a local scooby.
> - Is anyone depending on the current Cosmo GET behavior? How can we
> continue to provide this functionality?
read-only webcal-style integration with clients such as apple's ical
depends on the current behavior.
in general i don't like the idea of having the dav handler redirect
people to the web console. i'd much rather we can this notion of a
single uber "sharing url". we are conflating a couple of different
* visibility/access control: "public" or "private" calendars, "read"
or "read-write" or "free-busy" privileges
* resource format: "datal view" of a resource vs "repository
browser/raw html view" vs "web calendar view"
if i had my druthers, cosmo, chandler and scooby would understand
explicitly separate urls for a server calendar and would not try to
hide the distinctions between them.
btw, i think that once we have acl support throughout the ecosystem,
there will be very little need or desire for "public write access"
(read-write tickets). in fact, i wouldn't mind seeing the ticket
concept go away altogether in favor of a generic "public url" that
gives full read access (including free-busy). if a user desires
stronger/more granular access control or to give write access, he can
use acl and force his collaborators to obtain accounts on the server.
More information about the cosmo-dev