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

[Mimi Yin]

Hi Brian,

Thanks for going over these questions. I think we have a lot to talk  
about on Tuesday I personally have a better understanding of this  
feature list.

See more in-line. We don't need to hash all of this out on the list,  
that's what the design session is for, but your reply provoked more  
food for thought.

On Sep 1, 2006, at 12:07 PM, Brian Moseley wrote:

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

I think I was grouping Identity Management under Making Data Secure,  
rather than with Contacts Management. Other than security, what are  
other reasons for having identity management? e.g. Being able to  
track who changed what in shared data.

>
>> What about SMS?
>
> sure. choice is good :)

I think it would be good to sketch out when and why someone would be  
logged into their IM client but not have access to their PIM/calendar  
client (desktop, web or mobile device).

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

Wouldn't the data live on flickr anyway? I'm not sure about google. I  
put stuff on flickr from my local iPhoto client. I have my personal  
copy and then I have copies on flickr. I also back up the photos on  
the home server. But I don't put the photos on flickr from the  
server. I do it through the client. What would motivate someone to  
start from the server, rather than whatever client they were using.

One user motivation might be that the server has a better UI for  
managing my photos than iPhoto. (e.g. I can get at that UI from  
anywhere, even when I'm not at my computer).

But that assumes a Cosmo UI that can deal with all of these data  
types in a compelling way. And 'compelling' is subjective to the user  
and what they're trying to accomplish with the UI. Mobility might not  
be compelling for everyone. Hobbyist. Professional photography  
studio. For example, having Aperture's fancy photo management  
affordances might be priority #1, especially if I always have my  
laptop with me.

On a side note: Does this also assume a server that can deal with  
large media files? Is this already the case?

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

Cosmo UI as a dashboard for that stuff? Or some other client that  
interfaces with Cosmo to be a dashboard? Or perhaps both scenarios?

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

It's just a thought exercise to try and understand how this  
technology is being used and where it might be more readily adopted.  
Otherwise, how do we evaluate the value of this feature against all  
of the other things we'd like to do?

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

That would be a start. Pieter I think has also used it?

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

I understand those are the development reasons for implementing one  
technology over another. There is still the separate question of  
whether CalDAV lets people do something that Atom+GData doesn't or  
vice versa. Which would mean that we want to understand whether usage  
scenarios matter to us. e.g. Some of the security stuff you've  
mentioned above.

>
>> 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 I need to understand this a bit more, but I will wait for  
Tuesday.

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

That's unfortunate.

>
>> 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.
> _______________________________________________
> cosmo-dev mailing list
> cosmo-dev at lists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev