Subject: Re: Commit: autoconf and new import/export framework
From: Sam TH (sam@uchicago.edu)
Date: Thu May 03 2001 - 11:35:13 CDT
On Thu, May 03, 2001 at 09:14:27AM -0700, Paul Rohr wrote:
> At 10:48 AM 5/3/01 -0500, Sam TH wrote:
> >On Thu, May 03, 2001 at 11:27:44AM -0400, Dom Lachowicz wrote:
> >> [ap/xap stuff discussed]
> >>
> >> What I wanted to do was to add this to an ap_App baseclass. Seeing as how
> >> there is none (and I wanted to get every platform working with 1 LOC) I
> >> added this to xap_App. It's wrong, I admit as such. I did ask about it,
> >> though, and here are my thoughts:
> >>
> >> an IE_Imp or IE_Exp structure has the potential of being completely
> generic,
> >> and thus can live as an interface/abstract class. All my code does is call:
> >>
> >> IE_Imp::init(); IE_Exp:init();
> >>
> >> and that's all. Now, my argument is that we should have something like
> this:
> >>
> >> af/xap/xp/IE_Imp and wp/ap/xp/abi_IE_Imp which is a subclass. So now we
> can
> >> do something like the following maybe:
> >>
> >> IE_Imp::instance().init();
> >>
> >> Just a thought. If you want this out of xap-land, please add those 2 lines
> >> and the 1 #include to each ap_XXXApp's initialize function. I'm loathe
> to do
> >> it myself.
> >
> >As I said, I like your idea better than putting it all back in ap/.
> >So, if you do the af/xap/xp/ie* stuff, that would make me happy. As
> >long as we don't have af/ including ap/ stuff.
> >
> >Also, I think it would be good to hear what Paul thinks the plan used
> >to be.
>
> We planned to cross that bridge when we came to it. :-) Seriously. At the
> time, we didn't have very good use cases for what the real-world imp/exp API
> requirements for other products would be, so we just solved enough of the
> problem for AbiWord and left the results in wp/ap.
>
> Over the long term, we intended to generalize and move "enough" of those
> APIs to into af/xap land, but just didn't have enough data yet to decide
> where the xap vs. ap line should be drawn.
>
> However, the moment we decide to go ahead and externalize this functionality
> into dynamically-loaded modules, then a very strong case can be made that
> all the relevant imp/exp APIs and machinery should move *immediately* to XAP
> land. The last thing we want is for different apps to implement their own
> parallel imp/exp base classes.
Ok, here's how it looks to me.
ie_imp.cpp, ie_exp.cpp, ie_[imp,exp]_Graphic* should all go in
af/xap.
However, this can't happen immediately, since ie_[imp,exp].cpp both
include all the header files for all their importers. Didn't you have
a way to declare these dynamically, Dom? I thought you had checked
that in.
Once that happens, all of that stuff ought to move out of wp/.
sam th --- sam@uchicago.edu --- http://www.abisource.com/~sam/
OpenPGP Key: CABD33FC --- http://samth.dyndns.org/key
DeCSS: http://samth.dynds.org/decss
This archive was generated by hypermail 2b25 : Sat May 26 2001 - 03:51:01 CDT