Subject: Re: Commit: autoconf and new import/export framework
From: Paul Rohr (firstname.lastname@example.org)
Date: Thu May 03 2001 - 11:14:27 CDT
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
>> 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
>> af/xap/xp/IE_Imp and wp/ap/xp/abi_IE_Imp which is a subclass. So now we
>> do something like the following maybe:
>> 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
>> 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
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.
Until then, either of Dom's proposed approaches sound just fine.
This archive was generated by hypermail 2b25 : Sat May 26 2001 - 03:51:01 CDT