[Cosmo-dev] Understanding the Cosmo server side target users
twl at osafoundation.org
Tue Aug 29 22:50:20 PDT 2006
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
> 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...
> + External directory integration (LDAP, Kerberos (Apple has
> + 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
> + 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 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
> + "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.
More information about the cosmo-dev