{"id":289,"date":"2009-03-19T21:33:43","date_gmt":"2009-03-20T02:33:43","guid":{"rendered":"http:\/\/dilettantes.code4lib.org\/?p=289"},"modified":"2009-03-19T21:33:43","modified_gmt":"2009-03-20T02:33:43","slug":"in-search-of-a-bag-of-holding","status":"publish","type":"post","link":"https:\/\/rossfsinger.me\/blog\/2009\/03\/in-search-of-a-bag-of-holding\/","title":{"rendered":"In search of a bag of holding"},"content":{"rendered":"

Let me start this by saying this is not a criticism or a rant against any of the technologies I am about to mention.\u00c2\u00a0 The problems I am having are pretty specific and the fact that I am intentionally trying to use “off the shelf” commodity projects to accomplish my goal complicates things.\u00c2\u00a0 I realize when I tweet things like this<\/a>, it’s not helpful (because there is zero context).<\/p>\n

I’ve been in a bit of a rut this week.\u00c2\u00a0 Things were going ok on Monday, when I got the Jangle connector for Reserves Direct<\/a> working, announced and started generating some conversation around how to model course reserves<\/a> (and their ilk) in Jangle.\u00c2\u00a0 However, this left me without anything specific to work on.\u00c2\u00a0 I have a general, hand-wavy, project that I am supposed to be working on to provide a simple, general digital asset management framework that can either work on the Platform<\/a> or with a local repository like Fedora<\/a>, depending on the institution’s local needs or policies.\u00c2\u00a0 More on this in some other post.\u00c2\u00a0 The short of it is, I need to gather some general requirements before I can begin something like this in earnest, which led me to revive an old project.<\/p>\n

When Jangle first started, about 15 months ago, Elliot<\/a> and I felt we needed what we called “the Base Connector<\/a>“.\u00c2\u00a0 The idea here was that there were always going to be situations where a developer doesn’t have direct, live access to a system’s data, and they would need a surrogate external database to work with.\u00c2\u00a0 The Base Connector was an attempt to provide an out of the box application that could simulate the basics of an ILS and be populated with the sorts of data you would get from commandline ‘report’ type applications.\u00c2\u00a0 The sort of thing you can cron and write out to a file on your ILS server.\u00c2\u00a0 Updates in catalog records.\u00c2\u00a0 Changes in user status.\u00c2\u00a0 Transactions.\u00c2\u00a0 That sort of thing.<\/p>\n

After the amount of interest at Code4lib<\/a> in Janglifying III Millenium<\/a>, I decided to revisit the concept of the Base Connector.\u00c2\u00a0 Millenium’s (and to an extent, Unicorn’s, and there are no doubt others) lack of consistent database access, makes it a good candidate for this duplicate database.\u00c2\u00a0 I was hoping to take a somewhat different approach to this problem than Elliot and I had originally tried, however.\u00c2\u00a0 I was hoping to be able to come up with something:<\/p>\n

    \n
  1. More generically “Jangle” and less domain specific to ILSes<\/li>\n
  2. Easy to install<\/li>\n
  3. Customizable with a simple interface<\/li>\n
  4. Something, preferably, that could be taken mostly “off the shelf”, where the only real “coding” I had to do was to get the library data in and the connector API out.\u00c2\u00a0 I was hoping all “data model” and “management” stuff could be taken care of already.<\/li>\n<\/ol>\n

    In my mind, I was picturing using a regular CMS for this, although it needed to be able to support customized fields for resources.<\/p>\n

    Here is the rough scenario I am picturing.\u00c2\u00a0 Let’s say you have an ILS that you don’t have a lot of access to.\u00c2\u00a0 For your external ‘repository’, you’ll need it to be able to accomodate a few things.<\/p>\n