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

[Ted Leung]

On Aug 29, 2006, at 3:37 PM, Priscilla Chung wrote:

> PPD is trying to understand more about the server side target users  
> and I'd like to stir some discussion on the list before we proceed  
> with a design session next week.
>
> Based on the Cosmo Server wish-list specified by BCM (also listed  
> below):
> http://wiki.osafoundation.org/bin/view/Projects/ 
> SprintNotesCosmoVisionBrainstorming#ServerWishLi
>
> Could someone go though and explain in layman's terms what each  
> feature means and who would find it useful?

Here's a first cut...

>
> -Priscilla
>
> ---
>     +  External directory integration (LDAP, Kerberos (Apple has  
> these)
>           + Auth only, profile in Cosmo
>           + Profile in the directory

Some organizations use an LDAP (Lightweight Directory Access  
Protocol) directory server to store information about the people in  
their organization.   In these kinds of organizations, the IT groups  
want to see any piece of software which deals with accounts use the  
LDAP server to get information about people and their accounts.   How  
much information about the user (their profile) is stored in the LDAP  
directory varies by organization.    Microsoft's Active Directory  
speaks LDAP, along with the Kerberos authentication protocol.      
This functionality is useful to any organization which has an LDAP or  
Active Directory infrastructure already in place.   These  
organizations tend to be larger than the initial target audience for  
OSAF, and these organizations would be running their own instances of  
Cosmo as opposed to having LDAP access from our hosted service.

>     + Integration with single sign-on/digital ID
>           + Shibboleth/SAML/Library
>           + OpenID?

Digital ID technologies are in vogue nowadays.  One goal of these  
technologies is to make it easy to log into multiple sites with a  
"single sign on" identity.   Shibboleth/SAML is actually adopted in  
universities and very large companies.   OpenID has been adopted by a  
few "web 2.0" sites, like LiveJournal, and Zoomer, and a consortium  
of companies has funded 10 bounties for highly visible open source  
projects to integrate OpenID capabilities.

>     + The 2 item above imply some kind of framework in place to do  
> this
>
>     + ACL based security (Apple has this)
>           + Would also need a UI for managing these
>           + WEBDAV ACL extensions
>           + A UI which is part of Cosmo
>           + WEBDAV principle support - Kervin - use Cosmo as a poor  
> man's address book
>           + Handling groups - implies existence of group calendars

This is the fine grained security that has been mentioned many  
times.   At whatever point we decide that we need fine grained  
security, we will need to do this stuff

>     + CardDAV?

Think CalDAV but for address books instead of calendars.   This would  
let Cosmo act as an addressbook server.   There are some issues that  
would need to be resolved such as how this integrates (or not) with  
the address book functionality in Chandler (they are currently both  
based on vCards).   The other issue is that there are even fewer  
CardDAV clients out there than there are CalDAV clients.   Since  
Cosmo has no UI for entering or displaying contacts, there would be  
quite a bit of work do to get this to a useful state, unless Vinu has  
already built a web UI for contacts.   Also, I'm not sure what kind  
of disconnects there will be when we start implementing more of a  
Chandler like user interface in Cosmo.   The potential audience is  
people wanting to manage contacts in Cosmo.

>     + XMPP support

XMPP is another name for Jabber, which is the open IM protocol spoken  
by Google Talk, iChat (but not by default), and a host of open source  
and "alternative" closed source IM clients.   I believe that we were  
talking about using XMPP to do things like deliver alarms or other  
notifications to a desktop application from a Cosmo instance.    
People who are using XMPP or who want to get notifications via a  
desktop client app are potential users of this feature.

>     + Import existing data

A calendar without data in it is pretty useless.  I think that many  
people will want to import calendars from all kinds of weird calendar  
apps like palm pilots, or yahoo calendar or some such.   The more  
data we can get into the system the better off we will be.   I also  
think that writing data importers is a great community opportunity.

>     + Run Cosmo/Snarf as a windows service

A windows service is the correct way to run a server on Windows.    
People who are certified on Windows Server 2XXX know how to deal with  
services, but may not know how to work with a Java based server  
application.   In order to make it easy for people to install and  
administer Cosmo on Windows based servers, we should make it possible  
to run Cosmo/Snarf as a service.   Potential audience: all those  
small organizations running a windows based server who want to run a  
private Cosmo instance.

>     + Portlet/portal integration

The Java technology stack includes a specification for how to build a  
portal out of pieces.  It's not hard to imagine that a company  
building a web application which acts as a portal might like to have  
a calendar (or PIM) as part of the portal.   Of course, they could  
also choose to integrate that data right out of the hosted service  
using REST/GData/Atom/SOAP or some other "Web 2.0" glue technology.    
Target audience: people building portal applications

>     + Drag and drop microformat data onto the Cosmo UI

Microformats are a technology for embedding structured data into HTML  
web pages in such a way that programs can extract the data later and  
do something useful.   There are microformats defined for calendar,  
contact, reviews, social networks, keywords/tags, and more.   The  
goal of this would be to allow a user to drag a page that contained  
embedded microformat data into the Cosmo UI.  Cosmo would then read  
the embedded data and present some interface for manipulating/ 
integrating this data.     Microformats are an alternative approach  
to semantic web style ideas.

>     + Live clipboard/microformat

Live Clipboard is a technology developed by Ray Ozzie's group at  
Microsoft that produces real cut and paste for the web, and from the  
web to desktop applications.  Live Clipboard relies on microformats  
and other XML formats to do its work.   There is potentially a large  
audience for this -- anyone who would like to cut and paste data into  
and out of Cosmo at a "semantic level".   However, because Live  
Clipboard technology is not widely deployed, most people will  
probably not think of trying to cut and paste semantically, and even  
if they do, it may not work.

>     + More MyData?.org integration

MoveMyData.org integration

MoveMyData.org is an initiative to allow people to move their data  
from one web application to another.   The notion of open data (as  
opposed to open source) is starting to be discussed, and the notion  
would be compatible with OSAF's mission and values.   At this point  
MoveMyData.org is just getting started, there is no code.   Until  
there is something more substantial there, we can't do much.

>     + Google calendar support

I assume that this means being able to subscribe to Google calendars  
from Cosmo.   It would be good if we could persuade Google to  
cooperate with us so that Google calendar could subscribe to  
calendars on a Cosmo server.   People who have to interact with  
people who use Google calendar are the target audience.

>     + GData/Atom Pub support (BCM thinks this is more important  
> than most items on the list)

First some definitions:

Atom: a more tightly (in a technical sense) specified version of RSS
Atompub:  a companion protocol to Atom which specifies how to update  
resources on a web server by encoding the new data in an atom feed
GData: a set of extensions to Atom Pub (using the Atom's specified  
extension mechanism) which allow programs to update and search data  
in Google applications.   GData currently supports Google Calendar  
and Google Base

What follows is my take on the importance of this stuff

These technologies provide a standardized mechanism which we can use  
to allow 3rd parties to push data into Cosmo without using either the  
Cosmo web UI or Chandler.   In the simplest view, this is the  
"mashup" API for Cosmo, corresponding to the API's exposed by Flickr,  
del.icio.us, and various other web 2.0 applications, but set on a  
standardized foundation of Atom and Atompub.   If you look at the  
long term vision for Cosmo as being the web based counter part of  
Chandler, then these technologies give us and our users powerful  
capabilities for integrating Cosmo data with other applications,  
whether those are rich client or web applications.

Potential Audience:  any developer or scripter (or their users) who  
has data that they would like to store in Cosmo or retrieve from  
Cosmo.  Note that this is not developers who are working on the Cosmo  
code base, it is developers working on some other application.

>     + Federated Free/Busy - early stage

This is in regard to some very early stage work at CalConnect that  
would allow servers to exchange free/busy information.   It sounds  
like this is relatively far off.   Then again, so is 1.0.

>     + Storage layer research

I cannot for the life of me remember what this item was about.

>     + Integrating admin interface and file system browser into now  
> Cosmo UI - AJAXy

Integrating admin interface and file system browser into *new* Cosmo  
UI - AJAXy -- I think that the goal here is to improve the existing  
interfaces in Cosmo via AJAX pixie dust.   Its easy to make the case  
that we should improve the admin interface.   I'm not as sure about  
the filesystem browser because I'm not sure how much it is used.     
This is something that we ought to be able to find out though.

>     + Remote calendar subscription

I believe this item refers to allowing a Cosmo user to subscribe to a  
calendar on a different Cosmo server.   If Cosmo installations  
proliferate, I think it's easy to see why people would want this  
feature.

>     + "Virtual Cosmo" - partitioning a single instance

The goal here is to allow a single Cosmo instance to be partitioned  
so that it appears to be multiple Cosmo instances.  An example usage  
of this would be an ISP which install Cosmo and then wants to offer  
customers of its small business services a cosmo instance.   This  
allows the ISP to run and administer a single Cosmo, while each small  
business thinks it is getting its own dedicated Cosmo.   Potential  
Audience: most ISP's I think

>     + WEBDAV DASL

DASL (DAV Searching and Locating) is a specification for doing  
searching in a WebDAV environment.  The main page for DASL <http:// 
www.webdav.org/dasl/> indicates that DASL was never finished and that  
the IETF actually closed down the working group due to lack of  
progress.    Potential Audience:  well, they have to finish DASL first.

>     + More efficient synching - diffs, less HTTP transactions

This refers to efforts to make Chandler calendar syncing more efficient

1. diffs -- right now we sent the entire contents of an event even if  
only part of the event (like the time) has changed.   Sending only  
the information that changed would probably be more efficient
2. fewer HTTP transactions -- right now, calendar synching is using a  
large number of HTTP transactions (an HTTP transaction is a single  
request and response from the HTTP/Web/DAV server).  In fact, at the  
moment, I understand it is proportional to the number of events in a  
calendar.     It seems likely that we could reduce the number of HTTP  
transactions, which should improve syncing performance.  Potential  
Audience: anyone syncing a Chandler calendar to a Cosmo instance.

>     + EIM/morse code

EIM is the External Information Model that Morgen and PJE have been  
working on for Chandler.  It will be the basis of the Chandler backup  
and restore capability and the Sharing format between Chandler and  
Cosmo.   In addition, once we start implementing non calendar  
functionality in the Cosmo UI, we will need  a revamp of the  
internals of the UI since today it is hardwired for calendar data.   
As part of that revamp, we will need a model for representing  
information inside the web UI.   The EIM is a good candidate for that  
model.   Use of the EIM across Chandler and Cosmo will give us a  
single vocabulary that we can use which will help folks on both  
projects to speak the same language and be thinking in terms of the  
same concepts.     Potential audience:  Anyone who wants non calendar  
features in the Cosmo UI,  anyone making use of sharing, anyone  
wishing to dump/restore/backup their desktop Chandler.