Menu
|
A Context Plug-in(M3) (also known as a context provider) is an Eclipse/OSGI plug-in that implements the IContext and IContextFactory interfaces described here: Context Context Plug-ins are created indirectly by Higgins using the factory class registered with the 'Context' extension point. Some Context Plug-ins can be instantiated only once such as those connected to a corporate directory server, a website or an alumni association. Others may instantiated multiple times. For example, a user might create two BuddyList Context Plug-ins, one as "family" and another as "book club." Kinds of Plug-ins Standalone vs. Integrated Implementations: Contexts can be either standalone or integrated. A standalone Context can be created by the user and then populated with DigitalIdentities, their profiles and interconnections, etc. in a completely ad hoc manner. Standalone Contexts are not connected to any external system. Integrated Contexts are connected to an external system such as a directory server, identity system, shared space or communications system. Access to the contents of integrated Contexts must be negotiated in compliance with policies. Integrated Context Plug-ins act as bridges between an external computer mediated collaboration, communication or transactional context on the one hand, and the Framework's 'Context Interface'. This kind of Context Plug-in(M3) mediates between a stream of incremental updates to its internal representation on the one hand and some external system or service on the other. The external system may be located on the current host system, on a remote peer system, or on an external server. Some Context Plug-ins act as mini-databases that gather identities and relationships between them from (read-only access to) an existing system or network. An example might be an email Context Plug-in(M3) that integrates with and reads metadata from an email client and adds new DigitalIdentities and links to an internal private database as a user sends and receives emails. Some Context Plug-ins publish the Digital Identity changes to other remote Contexts in order to keep them synchronized. Some Context Plug-ins combine the communications function with a filtering or mediation function. They implement an information sharing policy that limits what information about the user's Digital Identity(s) will be visible to other users on remote systems. An example of this would be a Context that, while defining an overall population of DigitalIdentities , allows the DigitalIdentities on either end of a [Link] between them to control what information is visible to the other. [Note: This is an unusual kind of Context. More often rules that control what DigitalIdentities can see about other DigitalIdentities apply universally to all DigitalIdentities within the Context, as opposed to being controllable on a Link by Link basis as is described here]. Last Modified 4/18/06 5:14 PM | Hide Tools |