PROPOSAL: Generic Import/Export Architecture

[Sebastian Rittau <srittau jroger in-berlin de>]

                                    Proposal
                                    ========

                    GNOME Generic Import/Export Architecture
                    ----------------------------------------

The Problem
-----------

Many application wish to exchange data with external data sources and/or
data receivers such as IrDA devices (Palm Pilots, cellular phones, etc.),
e-mail programs, image devices (digital cameras, scanners, or screen shot
devices) or databases. Often it is not possible to take all possible data
resources into consideration when designing a new application; new data
resources (e.g. new IrDA devices) may come into use, and it may not be
feasible to integrate them into existing applications.

Currently there are different solutions to the data import/export problem.
GNOME Pilot was a GNOME 1 solution for exchanging data with Palm Pilots.
There are vague plans to port GNOME Pilot to the GNOME 2 platform, possibly
broadening the range of IR devices, but nothing concrete has emerged so far.

SANE (Scanner Access Now Easy) is a generic API for raster image scanner
hardware. Its design limits it to an image importing application.

The GNU Data Access and GNOME DB architecture provides a generic interface
for database access. This is more suited to applications that know (and need
to know) about the concept of a "database" and database queries. As such it
has a different scope than a generic data import/export architecture.

The Proposal
------------

A generic data import/export architecture for the GNOME 2 platform would solve
the problem of each application having to implement each possible way to
import or export data. Such an architecture would provide a common API
that allows applications to communicate with back-ends in a generic way.

Architecture
------------

The architecture would consist of three part:

* The central part is a slim core library that manages a list of backends
  and provides an API to access these backends for applications.
* The backends are divided into import and export backends (some backends
  will be able to handle both) and are responsible for doing the actual
  data transfer. For example there may be a PalmPilot importer/exporter
  or an e-mail exporter that will make use of the Evolution mail component.
* Frontends that make use of the central library's API and provide an
  easy-to-use interface for applications. Such a wrapper may provide
  Import/Export menu items (see examples below) or a Bonobo wrapper.

Generally, the library will search for importers/exporters on the system
(for example in a common directory) and will query them about the MIME
types they are able to process. While exporters may be able to use wildcards
(for example an e-mail exporter will be able to include any file type as
attachment), importers will be limited to specific MIME types.

Applications on the other hand can query the library for a list of importers
or exporters that support certain MIME types. The library will return these
im-/exporters as GObjects that are all derived from common base classes (e.g.
GObject->DataTransfer->Importer and GObject->DataTransfer->Exporter). These
base classes will provide an API to initiate data transfer.

Examples
--------

One possible front end for application use are im-/export menu items.

See http://me.in-berlin.de/~jroger/gnome/giea-menu.png for a possible
rendering of those.

An application would just call functions like

  static const gchar importable_mime_types[] = {
      "image/*",
      NULL
  };
  static const gchar exportable_mime_types[] = {
      "image/png",
      "image/jpeg",
      NULL
  };
  
  import_item = gnome_giea_import_item_new (importable_mime_types);
  export_item = gnome_giea_export_item_new (exportable_mime_types);

  g_signal_connect (G_OBJECT (import_item), "tranfer_initiated",
                    G_CALLBACK (data_transfer_cb), NULL);
  g_signal_connect (G_OBJECT (export_item), "tranfer_initiated",
                    G_CALLBACK (data_transfer_cb), NULL);

to deal with the data transfer. The front end would then take care of the
necessary communication with the core library.

What now?
---------

This is just a very early proposal to determine if there is interest in the
development of such an architecture. It is also meant to uncover flaws in the
presented design or to find alternative solutions. There are currently no
actual plans to implement such an architecture, but I hope that this proposal
will lead to more concrete plans.

 - Sebastian