Basecamp Importer
Submitted by Ryan on Tue, 11/20/2007 - 08:44.
| Project: | ProjectPier |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | patch - code needs work |
Jump to:
Description
I would like to see if we can possibly integrate some of this code into ProjectPier. Either as a separate script that generates a file to be fed into the installer, or possibly run directly within the installer script (perhaps both options).
The code has little documentation in it so feel free to ask
questions. Also, it's setup in a way that allowed it to run multiple
exports at once using a distributed network of machines on Amazon's
EC2 service - so a lot of the code is just for handling the EC2
stuff. The main interest would be in the convert/export.php file -
that's the meat of the export process.
| Attachment | Size |
|---|---|
| grid.zip | 107.9 KB |
Looks interesting.
You might also want to investigate the importer in RailsCollab, which instead of using the API reads from a dump file.
http://railscollab.rubyforge.org/svn/trunk/db/migrate_basecamp.rb
For our purposes, the file export/single_file.php seems to be actually better since most of the distributed network is not used.
However from the quick tests I have done, the includes and PHP modules have to be looked at better. By that I mean that I'm not sure this file was completely done.
Ryan suggested that instead of using this Basecamp Importer (more of an importer than an exporter), we break up the work in two parts:
* XML import/export of projects
* XML converter from a Basecamp dump to a ProjectPier dump which would then use the XML import/export module
Any suggestions on the definition of the XML format? Any XML expert around?
Found this today that might also be useful to look at. Its slightly dated though http://matthewhutchinson.net/articles/2006/12/18/basecamp-activecollab-importer
Some ideas:
It should be fairly straightforward to export XML that mirrors the SQL layout. The exporter could do a "mindless" dump of the db tables, with some intelligence to select subsets of tables for different kinds of exports, or project-limited exports.
A version code should be included in the XML output to help the importer identify conflicts or omissions.
The importer would need to ignore unrecognized fields. It should choke or warn on unknown versions.
---
A more intelligent design (as opposed to "mindless generic dump") may be called for, especially if we want to support exporting XML that is useful to other applications with different schemas or for use in generic XML handlers like Excel, IE, FF, etc.
---
A "full" export should be able to be used as a complete backup of the data (if not that of the "plugins").
---
The exporter and importer should both able to handle any custom plugin data. Of course the intelligence for this can be handed to the plugins via the Plugin API, when it exists.