Abdera is already structured so that it's core interfaces are in a separate jar than the parser implementation. There are, however, some additional utility and helper classes in the core module that will likely not be applicable to Rome. I'll definitely commit to helping do what I can to make this happen.
Btw, obviously the other members of the Abdera project would need to weigh in on it, but I would even be interested in changing the package names for the core interfaces so that they're less project specific. - James Dave wrote: > I get the feeling that ROME v2.0 is going to require some significant > development time and right now, there's nobody volunteering to do the > work. I'd like to find a way to move ROME v2.0 forward, but I'd also > like to take some interim steps to help ROME users. > > First, of course, I'd like to fix the current bug list and declare > ROME v1.0. It's not a lot of work, so I can probably do it soon. > > Second, here's an idea that might be helpful to those using Abdera for > Atom and ROME for RSS, it involves creating a "Common Atom object > model" and implementing that model in both ROME and Abdera. That way, > folks could: > > 1) parse RSS with ROME and easily convert it to an Abdera compatible > Atom model. > 2) parse Atom with Abdera and easily convert it to RSS via ROME > > Also, programmers would have to learn only one Atom model and not two > (plus ROME's model is a little quirky due in part Atom 0.3). > > Here's how we would do it: > - Use Abdera's Atom interfaces as the Common Atom object model > - Convince Abdera folks to release Atom interfaces in separate jar, > e.g. abdera-model.jar > - Re-factor ROME's Atom interfaces to implement the Abdera model > - Release ROME v1.5 with Common Atom object model support > > What do you think of that? Good idea? Bad idea? Is it worth the effort? > > - Dave >
