[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