[OPEN-ILS-DEV] documenting upgrade paths
I've created a new Upgrading section at the bottom of the Server Installation page on the wiki [1]. My goal is to document configuration changes required for upgrading from one version to the next. I'm in the process of back-porting some features from trunk into 1.2 in preparation for 1.2.2, so you will see the beginnings of the 1.2.1 to 1.2.2 documentation. I'll continue to update this as I back-port. The 1.2.0 to 1.2.1 path needs documenting, obviously. Any takers? ;) Comments/suggestions welcome! Thanks, -bill [1] http://open-ils.org/dokuwiki/doku.php?id=server_installation -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
[OPEN-ILS-DEV] Localization framework status
In the last few days, I've been working on the build/i18n/ directory of the Evergreen tree. I just wanted to give an update on my progress in getting a translation framework pulled together. Comments welcome! We will be using the Translate Toolkit [1] to convert files between DTD or JavaScript property file formats and PO format. My current Makefile assumes that the en-US DTD and JavaScript property files shall be the authoritative source from which the PO files shall be generated or updated. All locales other than en-US shall store the PO files in the Subversion repository (in the appropriate /build/i18n/po/ll-LL/) directory, and these locales shall generate their DTD and JavaScript property files generated from a set of PO files at build time. The release manager will be responsible for adding the generated files to the release tarballs. To generate a brand new set of PO files for a given locale, issue the following commands from the build/i18n/ directory (where ll-LL represents the language / region combination of IANA language tag subtag [2] and ISO 3166-1-alpha-code [3]): make LOCALE=ll-LL newpo This will create a new set of PO files in the build/i18n/po/ll-LL/ directory. If you have begun localizing the DTD or JavaScript property files and the files are in the build tree in a directory relative to the en-US files, such as was the case with en-CA and fr-CA for opac.dtd, you can then update the new set of PO files you just generated with the following command: make LOCALE=ll-LL updatepo This will update the set of PO files in the build/i18n/po/ll-LL/ directory. To generate a new set of DTD and JavaScript property files containing whatever localizations have been made for a certain set of strings: make LOCALE=ll-LL updatemoz This will generate a set of DTD and JavaScript property files for the requested locale in the build/i18n/locale/ll-LL/ directory that contain localized strings. If a localization was not provided for a given string, then the en-US string will automatically be provided. A basic set of unit tests for the preceding scenarios has been included in build/i18n/tests/testpo.py. Some thoughts: * The fr-CA and en-CA opac.dtd files that are currently checked into trunk should be deleted if we have general agreement that this is the direction we want to take. * This does not yet represent a complete set of localizable strings. Need to extend the framework to support localization of default database field values, fm_IDL.xml reporter labels, ils_events.xml, and eventually the Evergreen manual and contextual help. * The Makefile will need to be extended to automatically generate all of the supported / up-to-date locales to avoid too much manual work for the release manager. * The Makefile will need to be taught to place the generated files into the appropriate locations in the build tree to avoid too much manual work for the release manager. * Maybe we'll need to convert to something more flexible than a Makefile to ease the previous two items. * Still need to set up Pootle [1], use the Launchpad Translation Manager [4], or set up some other translation management tool to take full advantage of the benefits offered by the PO format. [1] http://translate.sourceforge.net [2] http://www.iana.org/assignments/language-subtag-registry - note that we might end up supporting three-character language codes after all - mea culpa Mike [3] http://www.iso.org/iso/english_country_names_and_code_elements [4] https://translations.launchpad.net/ -- Dan Scott Laurentian University
[OPEN-ILS-DEV] PATCH: oils_requestor.c (const-correctness)
This patch sprinkles the const qualifier over oils_requestor.c. In
addition:
1. It replaces the deprecated osrf_app_session_make_req function with
the equivalent osrfAppSessionMakeRequest function.
2. It plugs a memory leak where format_request() was calling itself
recursively without freeing the result.
3. In a couple of places it replaces buffer_data() with
buffer_release() in order to eliminate a round of malloc() and free().
Scott McKellar
http://home.swbell.net/mck9/ct/
Developer's Certificate of Origin 1.1 By making a contribution to
this project, I certify that:
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license indicated
in the file; or
(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source license
and I have the right under that license to submit that work with
modifications, whether created in whole or in part by me, under the
same open source license (unless I am permitted to submit under a
different license), as indicated in the file; or
(c) The contribution was provided directly to me by some other person
who certified (a), (b) or (c) and I have not modified it; and
(d) In the case of each of (a), (b), or (c), I understand and agree
that this project and the contribution are public and that a record
of the contribution (including all personal information I submit
with it, including my sign-off) is maintained indefinitely and may
be redistributed consistent with this project or the open source
license indicated in the file.*** trunk/Open-ILS/src/extras/oils_requestor.c 2007-11-17 14:52:23.0 -0600
--- trunk-mod/Open-ILS/src/extras/oils_requestor.c 2007-11-18 17:23:06.0 -0600
***
*** 12,18
char* authtoken = NULL;
static int do_request( char* request );
! static char* format_response( jsonObject* o );
int main( int argc, char* argv[] ) {
--- 12,18
char* authtoken = NULL;
static int do_request( char* request );
! static char* format_response( const jsonObject* o );
int main( int argc, char* argv[] ) {
***
*** 87,94
if(!strcmp(request,)) return 0;
! char* service;
! char* method;
char* tmp;
service = strtok_r(request, , tmp);
--- 87,94
if(!strcmp(request,)) return 0;
! const char* service;
! const char* method;
char* tmp;
service = strtok_r(request, , tmp);
***
*** 106,112
}
osrfAppSession* session = osrf_app_client_session_init(service);
! int req_id = osrf_app_session_make_req( session, params, method, 1, NULL );
osrfMessage* omsg;
while( (omsg = osrfAppSessionRequestRecv( session, req_id, 120 )) ) {
--- 106,112
}
osrfAppSession* session = osrf_app_client_session_init(service);
! int req_id = osrfAppSessionMakeRequest( session, params, method, 1, NULL );
osrfMessage* omsg;
while( (omsg = osrfAppSessionRequestRecv( session, req_id, 120 )) ) {
***
*** 128,134
}
! static char* format_response( jsonObject* o ) {
if(!o) return NULL;
int width = 20;
--- 128,134
}
! static char* format_response( const jsonObject* o ) {
if(!o) return NULL;
int width = 20;
***
*** 143,149
while( (key = fm_pton(o-classname, i++)) ) {
char* val = oilsFMGetString(o, key);
! jsonObject* item;
int l = strlen(key + 2);
buffer_fadd(buffer, %s: , key);
--- 143,149
while( (key = fm_pton(o-classname, i++)) ) {
char* val = oilsFMGetString(o, key);
! const jsonObject* item;
int l = strlen(key + 2);
buffer_fadd(buffer, %s: , key);
***
*** 176,184
free(key);
}
! char* data = buffer_data(buffer);
! buffer_free(buffer);
! return data;
}
char* jjson;
--- 176,182
free(key);
}
! return buffer_release(buffer);
}
char* jjson;
***
*** 188,197
for( i = 0; i != o-size; i++ ) {
char* d = format_response(jsonObjectGetIndex(o, i));
buffer_fadd(arrb, %s\n, d);
}
! jjson = buffer_data(arrb);
! buffer_free(arrb);
} else {
char* json = jsonObjectToJSON(o);
--- 186,195
for( i = 0; i != o-size; i++ ) {
char* d = format_response(jsonObjectGetIndex(o, i));
buffer_fadd(arrb, %s\n, d);
+ free(d);
}
! jjson = buffer_release(arrb);
} else {
char* json = jsonObjectToJSON(o);
[OPEN-ILS-DEV] config.xml_transform
Hi all, I was rumaging around in a fresh database and came across the config.xml_transform table. The rows inserted during the database build are: namenamespace_uri prefix xslt ----- - marcxml http://www.loc.gov/MARC21/slimmarc --- modshttp://www.loc.gov/mods/ mods /home/miker/MARC21slim2MODS.xsl Is this table used? Since it was created and populated during the install, I suspect the answer is yes. So, should I change the xslt column for mods to /openils/var/xsl/MARC21slim2MODS.xsl or one of the other MARC21slim2MODS versions. Should there be a an xslt value for the marcxml tuple? cheers, bill
Re: [OPEN-ILS-DEV] config.xml_transform
On 18/11/2007, Bill Russell [EMAIL PROTECTED] wrote: Hi all, I was rumaging around in a fresh database and came across the config.xml_transform table. The rows inserted during the database build are: namenamespace_uri prefix xslt ----- - marcxml http://www.loc.gov/MARC21/slimmarc --- modshttp://www.loc.gov/mods/ mods /home/miker/MARC21slim2MODS.xsl Is this table used? Since it was created and populated during the install, I suspect the answer is yes. So, should I change the xslt column for mods to /openils/var/xsl/MARC21slim2MODS.xsl or one of the other MARC21slim2MODS versions. Should there be a an xslt value for the marcxml tuple? Hi Bill: Word on the street is that that table is not yet being used in live code. (Word on the street meaning, I bugged Mike about this a while back and that was his response). -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] config.xml_transform
On Nov 18, 2007 9:48 PM, Bill Russell [EMAIL PROTECTED] wrote: Hi all, I was rumaging around in a fresh database and came across the config.xml_transform table. [snip] Is this table used? Since it was created and populated during the install, I suspect the answer is yes. No, not yet, but it will be. It is not in its final form as of now. It is safe to ignore completely. So, should I change the xslt column for mods to /openils/var/xsl/MARC21slim2MODS.xsl or one of the other MARC21slim2MODS versions. Should there be a an xslt value for the marcxml tuple? That is yet undecided. For now '---' has a special meaning of core format, but that may be changing in 2.0. -- 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
