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.

Among the tougher proprietary platforms for Open Source to gain ground in, consumer mobile devices is arguably the toughest. Google is hoping to challenge that with the release of their Android mobile computing platform and the first phone to use it, T-Mobile’s G1. Maybe now is the time to replace that chunky Nokia 3650 I’ve been hauling around for 7+ years…

I’m attending the NISO forum on collaborative library resource sharing, and heard a cautionary tale about making sure that a software project meant to be open source actually gets there.

Gail Wanner from SirsiDynix spoke today about the Rethinking Resource Sharing Initiative, an effort to revolutionize sharing of materials and services among libraries and their users. One of the products of the initiative was a Firefox plugin called GoGetter (previously known as GET-IT) that could grab information about a book from a web page and give the user a list of ways to get it, including online bookstores, the local library, resource sharing networks, Google Books, and so on.

A proof of concept was ready by June 2007 and was successfully demonstrated. However, work on it stalled — while the plugin was meant to be open source, apparently not all of the institutions involved in writing it (or employing the programmers involved) were prepared to let it go. Over the past year, various institutions have been signing off on releasing it under an open source license; while there’s been progress recently, GoGetter is not yet free. In the meantime, nobody has been able to play with it, improve it, or make it compatible with Firefox 3.

Lesson of the day: if you want to start an open source project, particularly if multiple institutions will be involved in writing it, it’s a good idea to make sure from the beginning that all parties are willing to release their work under an open source license.

There is a growing collection of “RFC”s for 3.2 features on the koha wiki. These are potential features that may be added in 3.2 or later. They’re put there to try to elicit community discussion to help steer them to make the best possible product. The 3.2 release manager, Galen, has indicated an interest in having these RFCs looked over by the end of next week, so I thought I’d take you on a quick tour of some of the more interesting ones. Here’s a quick look at some of the types of things being considered:

Administration improvements: The system of maintaining and using system preferences may get expanded by using roles and making the permissions collection more granular. On a somewhat related topic, there may be some work put into making independent branches work a little bit better.

Improvements to the user interface: In order to make Koha look and feel better to users, it’s possible we’ll extend the amount of AJAX elements that we use.

There are a handful of potential improvements for circulation. Among these is adding the concept of hourly circulation policies for some items. There are also a few that touch on holds, recalls, and fines.

Another interesting one would introduce summary holdings for grouping related items.

These are just a few of the RFCs that will get considered for features for 3.2 and beyond. You can help make Koha better by weighing in on how these may work together best.

A number of Koha developers and users met recently on the #koha IRC channel to discuss various project issues. Several project positions were voted on and are now filled:

• 3.2 Release Manager - Galen Charlton, LibLime
• Translation Manager - Chris Cormack, Catalyst
• Documentation Manager - Nicole Engard, LibLime
• 3.0 Release Maintainer - Henri-Damien Laurent, BibLibre

The position of QA manager for 3.2 remains open. The two candidates are Frédéric Demians (Tamil) and your’s truly. No decision was made, and the discussion will be continued on the koha-devel mailing list.

Several announcements were made:

• Galen will set up gitosis on git.koha.org to allow Henri-Damien to push
  patches to the 3.0.x branch.
• Henri-Damien announced that minor revisions of 3.0.x will be
  packaged and released every two months.
• Galen announced a date of 10 October 2008 for the developers to complete
  review of the RFCs for 3.2.

Various issues were raised that will be further discussed on the mailing lists:

• Coding standards for 3.2.
• Moving the Koha manual from Google Sites once www.koha.org is running Plone.
• Policies for ensuring that more patches are reviewed and tested.

The full log of the meeting is at

http://koha.org/cgi-bin/logs.pl?recall=recall&saved_query=2008-09-12%20meeting

or equivalently,

http://koha.org/cgi-bin/logs.pl?look=plain&startdate=2008091212:00:37&enddate=2008091213:30:01&search=Search