split IDL into per-class files
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Evergreen |
New
|
Wishlist
|
Unassigned |
Bug Description
For managing local customizations to the IDL, it would be convenient to split the monolithic fm_IDL.xml into a file per class. We propose an approach like this:
- break up the IDL into an XML snippet for each class, under Open_ILS/
- during installation, copy the snippets over to $SYSCONFDIR/
- add a script that gets invoked during installation (and which can be re-run at will and as part of autogen.sh) that scans through everything in $SYSCONFDIR/idl.d and reconstitutes $SYSCONFDIR/
Some points in favor of this:
* for anybody who does particularly extensive tweaking, having a bunch of small files rather than a single big one would ease dealing with merge conflicts
* adding a new class (e.g., for an IDL reporting source) would just be a matter of tossing a new file into fm_IDL.d and doing an autogen and service restart
* it won't be necessary to update clients that expect a monolithic fm_IDL.xml
Evergreen master
tags: | added: needsdiscussion |
+1.
I'm curious about the naming convention for the snippet files. fm_IDL.d/aou.xml? Or something more verbose?
The IDL-compiler script will need to be functional from within the repo without any assumptions about files getting installed. IIUC, the i18n code and certainly the Angular/Karma unit test data collector (staff/ test/data/ idl2js. pl) require access to a compiled IDL regardless of whether Evergreen is locally installed. Maybe that just means running the compiler during 'make' (at least before 'make install') or teaching these scripts to invoke the compiler themselves.
Not to muddy the waters, but while we're in there, should we move the IDL data from 'examples' and into a new 'src' directory (src/IDL/* or similar)? Low priority, obviously.