[OPEN-ILS-DEV] libjs

[Eric Lesage]

On Sun, 11 Feb 2007, Mike Rylander wrote:

> On 2/11/07, Mike Rylander <mrylander at gmail.com> wrote:
>> On 2/11/07, Eric Lesage <lesagee at iro.umontreal.ca> wrote:
>
> [snip]
>
>> > Now, if only libdbi would release ;-)
>> 
>> I have a /little/ sway there, since it's mostly my patches that have
>> gone in since the last release.  I'll give a nudge in that direction
>> and we'll see what happens.
>> 
>
> OK ... I've asked about a new release on the libdbi lists.  I'll let
> everyone know if/when I hear back.


Ok, thanks.

I've released my updated tree (20070213) with spidermonkey 1.6 and 
MARC::Record 2.0.0 and (lo and behold) a new dependency on django (which I 
didn't expect until 1.2, but hey, I'm not complaining). There's also a 
newer Unicode::Normalize.

Now, there's one issue we've already touched on previsouly, and that is 
the question of DB schema updates, and versioning tables. My ebuild 
doesn't address this at all. Most of the changes are in the reporter 
schema, so it's not too bad for now, but some are about permissions, etc.

I haven't had the chance (haha) to personally encounter these problems 
myself as a software developer, so I'm not sure what's the best way to 
handle this. But, I think the "initialization data" (default 
users/permissions) should be kept distinct from the schema itself -- it 
becomes clearer what should be updated, and what should stay inherited 
from the current setup (well... as long as a particular setup doesn't 
stray too much away from the distribution -- something for FIT).

There are of courses many issues with this, especially with decentralized 
software. I've not analyzed if/how you version interfaces elsewhere (i.e., 
for opensrf services) and how deep the schema affects the services... At 
some level one must take care that all services run on a coherent idea, or 
that provisions are made for multiple concurrent interfaces.

For a single-machine setup like I have, this is not a real problem (and, I 
admit, as I'm not faced with the problems, discussing the solutions for a 
replicated/distributed database is a bit speculative).


Now, on to something else... someone a while ago had shown interest in 
doing some work to transition to Autoconf[1]. Is that still the plan? 
Currently the only option in my ebuild is to install (or not) the staff 
client. The rest of the system is installed as a big monolithic hunk, 
which it should not be.

[1] http://list.georgialibraries.org/pipermail/open-ils-dev/2006-December/000161.html


Regards,

-- 
Eric Lesage