Services
========

Gaphor should be modeled around the concept of Services. Each service can
be registered on the application and be used by other services or other
objects living within the application.

Since Gaphor already uses the zope.component adapters, it seems like a good
choise to use zope.interface too as starting point for services.

Each service should implement the IService interface. This interface defines
one method:

   init(application)

where `application' is the Application object for Gaphor (which is a service
itself and therefore implements IService too.

Each service is allowed to define it's own interface, as long as IService is
implemented too.

Services should be defined as entry_points in the Egg info file (yes, Gaphor
should be executable as egg some day).

Typically a service does some work in the background.


Example: ElementFactory
***********************

A nice example is the ElementFactory. Currently it is tightly bound to the gaphor.UML module. A default factory is created in __init__.py.

It depends on the undo_manager. However, on important events events are emited.
(That is when an element is created/destroyed).

What you want to do is create an event handler for ElementFactory that stores the add/remove signals in the undo system.

The same goes for UML.Elements. Those classes (or more specific the properties) send notifications every time their state changes.

But.. where to put such information?

Plugins
=======

Currently a plugin is defined by an XML file. This will change as plugins
should be distributable as Egg's too. A plugin will contain user interface
information along with it's service definition.

Plugins are managed by a PluginManager (which is a Service).

