This document is a catch bin for random objectives and what we feel are requirements for success. It's not comprehensive and perhaps never will be.
Overall System
The overall system is designed to support the following goals. It is designed to be:
Open Source
SP is open source in order to (i) build credibility that the platform truly is secure, (ii) to allow contributions by a diverse community (iii) to eliminate cost as a barrier to wide diffusion.
Private and secure
SP stores all information about you and your relationships locally (on your computing device or storage device) under your direct control. It shares and exposes nothing unless you tell it to. Information is exchanged only under the conventions of the user and a context’s class.
Dynamic
SP has the ability to support rapid ad-hoc formation of contexts from whatever participants and organizations are available at a given moment.
Platform-independent
The SP framework is developed in Java and uses the Eclipse Foundation's Standard Widget Toolkit (SWT) for GUI independence.
Extensible, modular
The SP platform is a plug-in container based on the Eclipse Foundation's (new in 3.0) Rich Client Platform framework. This provides a mechanism for extensibility through the development of new plug-ins. Eclipse provides sophisticated plug-in runtime management as well as framework for modular graphical interfaces based on views, editors, perspectives, etc.
User Experience
Immediately useable: the base app
The base application is bundled with the SP platform. After you download and install the SP app you can start it up as a conventional software application and immediately begin using it.
Easy to install
Multiple contexts and context classes
SP supports the creation of any number of "contexts" or shared contexts from an extensible set of context classes. Some context classes can only be instantiated once. Others can be instantiated any number of times. You can belong to any number of contexts simultaneously. You define and maintain a distinct persona (profile) for each of your contexts.
Diversity of Context Classes
Through plug-ins SP supports a very wide range of context classes. Each contributes its own user profile editor window to the GUI, and has its own distinct look & feel. Each context class defines and implements its own information visibility/sharing contracts between members.
Background operation
The SP base app is not something that you will use hour by hour or necessarily every day. You continue to use email, web browsers, instant messaging, spreadsheets, etc. as you normally do with no change in behavior required. The tracking aspects of SP are designed to run quietly in the background and out of your way.
It is very much like an IM app. You (or your computer's startup routines) start it up, and its window appears on the screen. If you close its window, it stays running in the background. To really quit the application, you maximize its window and select "Sign off".
Human interface
As far as possible it should look and feel like a native application. Something very simple, almost like the AOL IM client. The first reaction should be "oh, that's all it is?"
Loose coupling with apps
The user is able to use everyday applications, e.g. email, without the SP platform running at all because they may not want to wait to start up SP some of the time. This should be true even if the application is tightly coupled to an SP-specific add-in.
Development tools
Developing plug-ins does not require the use of specialized tools (e.g. Eclipse Modeling Framework.)
Context Plug-Ins
An API is provided to allow a developer to create a new context protocol plug-in.
The developer has a high degree of control over the look and feel of the context's profile editor view's appearance.
Caching
The platform caches copies of user profiles returned as a result of queries to other SP peer instances. Information in the cache has a 30 day time-to-live.
Privacy
The architecture is designed to protect the user's data and the data of any other user cached locally. For example, plug-ins do not have direct access to the SP data model.
Uses JUNG
The SP data model is an extension of JUNG's data model. A node in SP is an extension of a JUNG vertex. A link in SP is an extension of a JUNG edge.