This from the Koha Mailing List:

There is a question on the table if this meeting announced as an American Conference for Koha should be more like a Koha Con 2009 with the format similar to 2006.

With that we would like to schedule a meeting to discuss on IRC the KohaCon possibility.

There is a wiki at: http://wiki.koha.org/doku.php?id=kohacon2009 - to better help organize some of this…

• Who wants/would be interested in attending this IRC (and eventually a full conference?)

• What days of the week are best for this IRC? (sooner the better)
• Times are best for you - GMT for this IRC? - http://wwp.greenwichmeantime.com/
• In this discussion we would talk if a developer meeting is of interest?
• Should it be pre or post the Conferece that is being planned for April 16/17 in the US?
• How much time should be considered 1 or 2 days?
• What should those days look like?
• Where is the best place to house them (how many is of concern along with other needed items if they are to meet)

In addition I would love to hear any input this group might have for the April 16/17 “conference” as well. Presentations - workshop etc… how it should be structured for a meeting of users and developers.

David Schuster
dschust1@tx.rr.com
Plano Texas
going live Jan 5th, 2009 as a LibLime customer! - this is open to all koha users and those interested. More information on the schedule to come after I figure out interest.

Diane Hillmann of cataloging, metadata, and DCMI/RDA fame and her “partner in crime” Jon Phipps have started a new blog called Metadata Matters:

From her first post:

So what can you expect to read about on this blog? We have some projects we can talk about, and some we can’t, so we’ll talk about some of our current “talkable” projects like the NSDL Registry (we’re working on some ideas to expand that development effort—watch this space), the RDA formal representations (see the DCMI/RDA Task Group page for more info on this), digital libraries in general, changes and new developments in the library environment, etc. Jon will talk more about the technology side than I will, but that’s the good news about this blog—it’ll be a little of everything.

I’ve been doing some work recently to see if Koha could benefit from using an ORM tool like DBIx:Class. This would help abstract away the database interactions for developers. I’ve produced an example implementation of how we could do this and sent it to the Koha-devel list a few times in hopes of gauging how likely it is that Koha could move in this direction soon.

Since I didn’t receive much criticism and actually got some good advice and some offers of assistance, I’m hoping that I can keep working on this project until it gets accepted into Koha. To that end, I’ve started a wiki page where I can describe how I expect to eventually get to use DBIx::Class in Koha and how I envision us getting there. If you’re interested in helping me figure out a good way to go about this, or if you’re just interested in reading a bit about one possible future feature in Koha, take a look at that page and feel free to edit it

I’m hoping that this project makes it easier to contribute to Koha. That means that I may not have the best implementation in mind right now. I want to hear from you on how we can make it better. Thanks!

I’m pointing out a change that Frédéric Demians made recently to the Git usage page on the Koha development wiki.

In order to avoid mangling non-ASCII characters in commit messages for patches submitted via git-send-email, Frédéric suggests forcing the Content-Type header in patches prepared by git-format-patch to specify UTF-8. This can be configured like this:

git config --global format.headers "Content-Type: text/plain; charset=\"utf-8\""

A colleague of mine is very frustrated with his campus IT people just now.  The library would like to run MediaWiki, but the campus IT boss will have none of it.  “It’s open-source, and open-source is insecure,” he claims.

I have a big communications gap with such people–we might as well not be speaking the same language, because we have no common frame of reality to work from.  This individual just doesn’t realize that, like high-fructose corn syrup, open source is in just about everything these days.  This particular institution is using Apache, for instance, for all of its’ web servers.  The journalism department standardized a year ago on MacBooks and iMacs (which run OS X, which has lots of open-source bits at its’ core).  And yet, a huge percentage of their security-related helpdesk tickets relate to security problems on Windows Server instances.  Go figure.

It’s been contended before, and I agree, that open source software is inherently more secure.  In a closed-source project, the only white-hats that are looking at the code work for the project, while the number of black-hats is effectively limitless–and in fact, the bad guys take it as a challenge, I suspect, to try to hack at those programs.  In LibLime’s open-source world, the number of security-positive, well-trained people that are looking at the code, finding and fixing problems, is also not artificially limited.

But the head-in-the-sand IT boss persists: “But then, everyone can see the vulnerability!”  What he’s ignoring, clearly, is that anyone can fix the vulnerability, instead of having to wait for the vendor to come out with a patch.   Maybe we’ll never get through to some people.  But they’ll retire, eventually.

What about you?  Find an open source project that does important things for you, and support it.  Even a little help, with documentation, say, or even a little bit of code, or testing it out on a platform that the developers haven’t got access to, will help that project move along, and is greatly appreciated by the project team.  If you’re not equipped to do that, just send the team a note, and let them know you’re using their work.  They’ll appreciate that, too!

‡biblios currently has some (as of yet) little used code which sends signals at certain key events to any javascript listeners who may be interested: opening a record for editing, saving a record, performing a search. This is good for notifying listeners of the event with some data relating to the event.

With this mechanism, however, it isn’t possible for the listeners to act as filters for the data. I’d like to be able to configure ‡biblios to run marcxml data through a series of arbitrary filters (possibly even allowing for the filters to perform AJAX operations to allow for server side processing).

What I imagine is something alongs these lines:

In the ‡biblios configuration file, a section defining filters for certain events:

<filters event="save">
  <filter name="update003">
     <code>update003(marcxml)</code>
  </filter>

  <filter name="update999">
     <code>update999(marcxml)</code>
  </filter>
</filters>

‡biblios would then, at each predefined event type (e.g. save) send out the save signal but also run through any filters defined in the configuration file, evaluating the javascript code contained therein. Each type of filter would know to expect the marcxml as a parameter and would be required to return the (possibly modified) marcxml to the caller.

I imagine some javascript code like this to make this happen:

  // marcxml is an xml document
 var filteredxml = marcxml;
 for( var i = 0; i < filters.length; i++) {
   filteredxml = eval( filters[i].code ); // filters[i].code accepts the already defined marcxml variable
}
return filteredxml;

In this way, administrators or developers could modify the behavior of ‡biblios with respect to marcxml handling simply by writing a javascript file containing functions to be referenced from the biblios configuration file. The javascript file containing these filter functions would be loaded into ‡biblios via the already existing plugin loading mechanism.