From: Tim M. <tmm8@Lehigh.EDU> - 2008-07-03 16:01:20
|
Andrew Nagy wrote: > I fear we are making mountains out of molehills here. In order for a > vendor to comply with VuFind, they will have to comply with Jangle - > so from their perspective, it shouldn't make a difference. When was this decision made? I don't really think this is only a molehill. In fact, I think this significantly changes the entry point from which libraries get to VUFind. To me, this seems like Jangle has been made the de facto standard of the ILS-DI and, now, VUFind. Am I mistaken? If I am going to recommend that VUFind be the replacement of our OPAC, then I need to be sure that we can support it. Using an ILS driver built by our ILS API community and sanctioned and enhanced by our ILS vendor as their first-steps contribution to the ILS-DI is supportable. Depending on Jangle, at this point, is not. I now have 18 months to either have VUFind at a stable, supportable place to completely replace our OPAC (including user interaction) or we'll need to purchase an upgrade from our ILS. I'm not confident I can do that putting our eggs into the Jangle basket. > Especially if they adopt jangle themselves to make their DI products > work with other systems - they would probably be more receptive to > working with Jangle over VuFind. But again, this isn't happening > tomorrow. The migration to Jangle would hopefully be seamless and > create much more possibilities with VuFind. As I see it, only a > win-win situation. I think you are putting way too much hope in the vendors here. What is their incentive to accept Jangle? There is none. Honestly, they really have no incentive to even follow the ILS-DI. Getting a vendor to create some basic open API will be a major, major, major accomplishment. >> So the next logical question I have is have you made a firm >> decision to no longer have individual drivers for ILS's and >> eventually have Jangle do this all? And secondly, what happens >> when Yangle (yet another next-generation library environment) comes >> out? Will VUFind support that, too? > > Nothing is ever set in stone with Open Source software - but I see it > as a clear decision to utilize Jangle as the ILS Layer for VuFind > just as we use Solr for the searching layer. I'm not trying to rock the boat here, but I honestly don't see how this is a clear decision. I don't think that I'm alone, but that's why I need to understand why you think this is a clear decision. Comparing it to Solr is not a good comparison. Solr has the backing of the Apache community - a community that dwarfs code4libbers, let alone the % of code4libbers working on Jangle. Let's take this from another angle. From the beginning of this project, VUFind provided a service application to all libraries. The required input was MARC records converted to XML. VUFind ran. If you want real-time connection to your ILS, then you wrote a driver. The level of integration you want with your ILS is one's choice and one's ability to do it themselves or work within their ILS vendor's user community - exactly what many of us are doing. But the sense I am getting now if you want any connection to your ILS, it will be required to be Jangle. That takes the skills that we have invested in our own ILS APIs out of the equation and makes us dependent on an independent application that has no foundation (yet) to be a factor with our ILS vendor. We have that ability because we have the relationship. Jangle folks as a whole do not. So from this point of view, if you want to support Jangle with VUFind, that's great - go for it. But don't do it at the expense of taking away the ILS Driver philosophy. That removes the agnosticism that VUFind was initially marketed as, but now required to know Jangle and be able to support Jangle. (which again I re-iterate: don't expect everyone to be able to support Atom Publishing Protocol.) Does this make sense? Tim Tim McGeary Senior Systems Specialist Lehigh University 610-758-4998 tim...@le... Google Talk: timmcgeary Yahoo IM: timmcgeary |