allura-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cory Johns <cjo...@slashdotmedia.com>
Subject Importer framework
Date Thu, 11 Jul 2013 18:43:29 GMT
We're beginning to focus on improving and expanding our support for
importing and exporting project data to and from Allura, and as part of
that we need to develop an extensible framework for adding new import
mechanisms to Allura and exposing them in the UI.

New importers will need to be able to advertise both what tool they are
able to import data for as well as what external source they will import
their data from.  The discovery mechanism will need to be able to list the
importers available by tool type, so that a given tool can provide a UI to
import from any supported source, or by source, so that we can provide an
integrated mechanism to import an entire project and all supported data
from a source.

Entry points are an obvious choice for discovering importers, whether they
are provided by the tool itself or a third-party library or Application to
extend the tool's ability to import.  My thought is to have tools or
libraries add entry points to the "allura.importers" group, with each entry
point class providing import capability for a single tool from a single
source.  Each importer would then have attributes indicating the tool it
applies to, the source it imports from, and the controller for its UI.

Here is an example importer stub with the attributes I'm thinking of:

    class GoogleTrackerImporter(class):
        target_app = forgetracker.tracker_main.ForgeTrackerApp
        source = 'Google'
        controller = forgeimporters.google.TrackerImportController

To support full-project imports, a library could expose an entry point in
the "allura.project_importers" group, which would point to a controller
that coordinates importing an entire project from an external source.

I believe that will allow us to tie together importers in an extensible
way, yet give each importer flexibility in how it implements its import
logic.

What do you think?


- Cory

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message