[LibX] Questions about libx

Godmar Back godmar at gmail.com
Fri Apr 28 14:32:35 EDT 2006


Two meta comments about code libraries, LibX etc.

I believe that there is already a large community that shares code
(code4lib, etc.) and that's wonderful. LibX wants to be part of it,
and has the necessary license and transparency in the development
process for that.

However, a specific "code repository" - where people upload code for
others to download, maybe as module, is doomed to failure (I know of
no successful open source project that followed this model and was
succesful.)

Rather, code needs to be used in order to live and not rot. This is
what we hope to accomplish with LibX. As such, if someone wanted to
use the infrastructure to implement WAG the dog type services, or any
unAPI stuff, we would be happy to include that in LibX so it would be
continously used by libraries. People can also use parts of LibX or
contribute parts to it, or take parts from it.  But taking out parts
of LibX and putting them in reusable form with the hope that someone
might use would not be a wise investment of time for us. (But suppose
somebody were to take the catalog code or openurl, package it into a
library, then use it for another project, we'd certainly change LibX
to use that library as well.)

 - Godmar

On 4/28/06, Ross Singer <ross.singer at library.gatech.edu> wrote:
> On 4/28/06, Jeremy Dunck <jdunck at gmail.com> wrote:
>
>
>
> > I'm sure there are hundreds of working user scripts on us.o, but it's
> > not obvious which are which.  That's kind of the point-- there are two
> > things at work here.  There's the perception of GM's fragility and in
> > that sense, I think LibX is really in the same ballpark.  You're still
> > depending on DOM manipulation on a known tree-- you're just less
> > likely to break since OPAC upgrades are few and far between.  A user
> > script coded against an OPAC would be similarly stable.  ;-)
>
>
>  This is a very good point (and why, ultimately, I gave up on development of
> WAG the Dog).  Certainly the widespread adoption of parseable cues, such as
> COinS or microformats, would help considerably.  Until then, it's constantly
> a matter of keeping up with what's breaking (and writing new scrapers for
> new services that appear in the wild).  I found I didn't have the energy or
> the interest to do this and the introduction of LibX gave me an easy out :).
>
>
> > The second thing is that you're making a domain-specific page
> > modifier, and (as I hope I've made clear) I think that's useful.
> > (I also think it'd be nice if an library-related code library came out
> > of this.  Dealing with the various OPAC flavors, xISBN, OpenURL, and
> > COiNS could, I think, be usefully abstracted for extensions other than
> > LibX.)
>
>
>  I would really love to see something like this.  The nice part of the
> library world (well, it's actually very frustrating, but this is one
> advantage) is that the low number of actual vendors means that creating
> libraries for services that don't have a standards based interface for is
> fairly small.  Such a clearinghouse might serve the double purpose of
> informing people how to actually implement (and use) standards based
> approaches to their services.
>
>  Then again, nobody may contribute to it and it will wither on the vine,
> like so many other initiatives in the past.  However, I'm encouraged by the
> work that Ryan Eby, David Walker and Rob Casson have done to form a similar
> community around the III XMLOPAC:
> http://wiki.lib.muohio.edu/xmlopac/index.php/Main_Page
>
>  It would be nice to see similar efforts for other products.
>
>  -Ross.
>
>
>


More information about the Libx mailing list