[OPEN-ILS-DEV] Proposal: Versioned Add-on Packages
Mike Rylander
mrylander at gmail.com
Fri Feb 20 13:19:30 EST 2009
On Fri, Feb 20, 2009 at 11:12 AM, Scott McKellar <mck9 at swbell.net> wrote:
> --- On Fri, 2/20/09, Mike Rylander <mrylander at gmail.com> wrote:
>
>> From: Mike Rylander <mrylander at gmail.com>
>> <mck9 at swbell.net> wrote:
>> > --- On Thu, 2/19/09, Mike Rylander
>> <mrylander at gmail.com> 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: miker at esilibrary.com
| web: http://www.esilibrary.com
More information about the Open-ils-dev
mailing list