--- On Fri, 2/20/09, Mike Rylander <[email protected]> wrote: > From: Mike Rylander <[email protected]> > <[email protected]> wrote: > > --- On Thu, 2/19/09, Mike Rylander > <[email protected]> wrote: > > > > <snip: proposal on how to make IDL files easier to > upgrade in > > the presence of customizations> > > > > To summarize my simple-minded understanding of your > proposal: > > > > -- Represent standard IDL classes in one file; > > -- Represent extension classes and site-specific > classes in a > > separate IDL file; > > -- Use a third IDL file at runtime; > > -- Regenerate the third IDL file as needed, by merging > the first > > two whenever either of them changes. > > > > Yes. Though there would be a file per change, generally > one per > add-on or local customization.
Okay, so the customizations would be stored as a series of diffs, or patches, or something like that, rather than a single file. When it's time to regenerate a working IDL file, we apply the patches, in the appropriate sequence, and then add the results to the standard IDL file. At least conceptually. I won't quibble over the exact mechanism. Conceptually -- at least in the initial proposal -- the IDL merge process would copy the standard IDL without change, and then append some other stuff based on the customization diffs. Scott McKellar http://home.swbell.net/mck9/ct/
