On Fri, Feb 20, 2009 at 11:12 AM, Scott McKellar <[email protected]> wrote: > --- 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. >
Exactly. :) -- Mike Rylander | VP, Research and Design | Equinox Software, Inc. / The Evergreen Experts | phone: 1-877-OPEN-ILS (673-6457) | email: [email protected] | web: http://www.esilibrary.com
