[imc-sf-active] [imc-sfa-servers] maintaining popelin - the server hosting your imc

[mark burdett]

Hi, well with a copy of a MySQL database and the uploads directory I 
could have a pretty quick* turnaround on a Drupal module capable of 
running the migration, via a mix of SQL and PHP.  It seems like extra 
work to write scripts for generating and parsing XML files, so if I was 
working on it I wouldn't bother with this intermediate step.  Of course, 
go for it if you like the idea.. :)

* there are some things that I probably need some trial and error with 
setting up before I run a Drupal migration, like how best to potentially 
use http://drupal.org/project/media to represent attachments..

--mark

On Thu, 03 Mar 2011 06:31:48 -0500, Daniel P wrote:
> On Wed, Mar 2, 2011 at 5:11 PM, mark burdett <mark at indymedia.org> wrote:
> > Having previously done a sf-active to drupal migration I'm not sure it's
> > worth the extra steps of this intermediate conversion (yet another
> > schema to have to know, and more insert into select from queries to
> > write).  Maybe you just need me to document sf-active as I've been doing
> > on IRC today w/ occam?  But if we do want or need this step then I'd ask
> > what's the schema for this intermediate representation?
> 
> Detailed documentation of the schema would no doubt be valuable, but I
> think we can save some work instead.  I wasn't thinking of another SQL
> schema, I was thinking more about XML.  I think there are decent
> existing XML schemas already defined that tools exist for.  I was
> looking at NITF (www.nitf.org) because I had a passing familiarity
> with it, and then a bit of digging revealed BlogML
> (http://blogml.org/)[1].  People could then leverage existing BlogML
> import tools to get to whatever CMS they want.  If there is data that
> we can't massage into BlogML, we can export it separately, and those
> so inclined can write tools to iterate over our extra metadata and
> modify their imported documents to reflect what they want from it.
> 
> The other advantage to this approach is that it lets us use PHP to
> generate the XML.  I was having the most luck at using sf-active code
> itself to simply give me an article PHP object, and then using the
> sf-active code itself to progamatically create drupal nodes.  People
> importing to languages which aren't PHP don't have the privilege of
> being able to do that, so I figured writing a PHP tool that leveraged
> existing sf-active code to create a more portable serialized
> representation of the object (in XML) would let others get the benefit
> of using sf-active's code to parse sf-active's schema.
> 
> I think, specifically, about why I thought it was easier to use the
> PHP to parse the schema is that getting a representation of a single
> article is not easy in SQL in sf-active's database. It's been awhile
> since I looked, but I believe you need to join webcast onto itself
> (and in doing so you're getting photos as well as comments), and
> figuring out what is hidden or not is also a bit tricky (or maybe I
> couldn't just keep track of the several single character possible
> values for the relevant field).
> 
> I think that aiming for our tools to create an interchange format that
> is a standard, or at least heavily based on a standard, is the right
> thing to do because inevitably not everyone is going to want to import
> their site to the same target, and a lot of people would find it
> easier to iterate over a set of objects than over a set of tables.
> One thing I've been stuck on locally in conversation with others in
> Pittsburgh IMC is that there's a lot of contention over what CMS
> should be used (i.e. drupal or wordpress) and writing tools that would
> be useful to import to anything therefore appeals to me.
> 
> Daniel
> 
> [1] the name BlogML is a bit unfortunate, because I doubt any/many of
> us want people to think of IMC sites as "blogs" (given that term
> largely refers to "opinion" and not "news" sites) but hey,
> schema-wise, I think they're pretty close.