[Cosmo-dev] Understanding the Cosmo server side target users

[Brian Moseley]

On 8/31/06, Mimi Yin <mimi at osafoundation.org> wrote:

> There seems to be heavy overlap between:
> + LDAP
> + Single Sign-on technologies: Shibboleth/SAML versus OpenID
> + ACLs
> + CardDAV
>
> The Usage Patterns include:
> + Contacts Management / Directories

contacts management is a different area than identity management,
which is what the delegated authentication/single signon stuff is all
about. contacts are about people i know, whereas identity management
is how the server knows anything about me.

> What about SMS?

sure. choice is good :)

> My main question is: Why would you upload your data to Cosmo, as
> opposed to just uploading it directly to the target destinations
> (e.g. Google calendar, Flickr, etc) Or is this more for someone
> administrating a service?

the specific line item here was in regard to migrating your calendar
from an existing client or service into cosmo.

to your question, there are plenty of people in the world who don't
want to give their stuff to flickr or google and want to have full
control over it themselves.

i can also see the value of integrating with services like google and
flickr so that i don't have ten different sites to visit to look at or
manage all my stuff. i'd love for cosmo to be a dashboard for that.

> What do you mean by portal applications? Yahoo the portal? Our wiki
> as a portal? I guess, what makes a portal a portal as opposed to just
> a website?

there is a specific usage of the term portal that means a web site
which aggregates content from other sites to display in its own
context. my personalized google home page is a great example.

> Are there some examples of prominent sites that support microformats
> you could point us to? What other clients support this? Would it be
> safe to say that currently, this primarily for "public" information?
> (as in, not personal invitations people receive in email).

i don't think we've dreamed up all the potential uses for
microformats, but i don't like the idea of limiting ourselves in that
way.

> I guess we'll have to gain a better understanding of Google
> calendar's user base. :o)

interview me :)

> What usage scenarios does Atom support, as compared to CalDAV,
> WebDAV, CardDAV, RDF, microformats, etc. What does it do better than
> the above listed technologies. What can't it do as well?

it's easier for people to write code in popular scripting languages to
talk atom than the webdav family of protocols. the dav stuff requires
some heavyweight processing and has security requirements that atom
does not.

> Aside from end-user scenarios, what would motivate someone to
> implement Atom as opposed to any of the other above technologies.

not needing extremely sophisticated calendar queries, wanting simple
access to your calendar data from scripting languages or from code
executing within the browser.

> I think we should do a workflow exercise on this one as well. How
> might this feature manifest itself to end-users using calendar clients?

no idea. still nobody has explained to me what that calconnect thing
is all about.

> So this is the ability to query the server? As opposed to pullding
> the data down into your client first and then searching it there?

yes. with webdav that could be prohibitively expensive, if the content
in the server is say large documents.

note that caldav gives clients the ability query the server for
calendars specifically.