Jangle: Why such an emphasis?

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Jangle: Why such an emphasis?

Tim McGeary
Ok, so I'm nearly caught up on all my listserv emails while I was on
vacation, and I have a question that I'm confused about.  There were two
topics here on VUFind-Tech that I am particularly interested in (marc
holdings and web service) and in both cases, there is a specific
emphasis on including the Jangle project.  Including the Jangle folks in
the loop is fine, but I don't understand why the sudden emphasis on it?

Is Jangle all of the sudden expected to be the be-all-end-all of the ILS
drivers for VUFind and other ILS-DI applications?  Please correctly me
if I'm wrong, but so far, it just seems like yet another layer to get in
between the ILS and the application we are trying to use.  If it is
meant to be a single source for vendors to discuss, like the de facto,
or at least first, implementation of the ILS-DI specifications (whatever
those specs really end up being), I don't want to put all of our eggs
into that basket.  Especially since SirsiDynix has been clearly
interested in working on assisting their customers with ILS-DI issues.

So before we keep throwing topics into the Jangle baskets, can we have a
frank discussion about the importance and weight VUFind is putting on
Jangle?  It has been difficult enough to work on the ILS driver code,
get SirsiDynix's permission in writing (which has been accomplished) to
release that API code to other SirsiDynix customers wanting to use
VUFind, I want to be sure I understand just how this conversation with
SD will continue and/or change based on this communities interest,
emphasis, or dependence on Jangle.

Within the specific topics Naomi brought up, MARC holdings, in some
manner, has to be a part of the index within VUFind in the near future
for us to be able to use VUFind in production.  To give it even more
emphasis, we are now on a ticking clock of an end-of-life statement for
our current OPAC.  If VUFind is to be a viable replacement, I have until
Q1 of 2010 (not that far off) to have EVERYTHING SD offers in VUFind and
our Unicorn/Symphony driver.  That includes user accounts, request, etc.
  75% of that is not a concern of the VUFind community, but MARC
holdings, item types (not defined in the bib record) as facets, and the
process of doing incremental adds, updates, and deletes (export/import
or web service) to the index are.

Let's discuss.  I want to understand this better.  Thanks!  :)

Cheers,
Tim

--
Tim McGeary
Senior Systems Specialist
Lehigh University
610-758-4998
[hidden email]
Google Talk: timmcgeary
Yahoo IM: timmcgeary

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Vufind-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vufind-tech
Reply | Threaded
Open this post in threaded view
|

Re: Jangle: Why such an emphasis?

Andrew Nagy-2
There are many reasons for abstracting the ILS Drivers to Jangle.  However, I would say that the main argument is from a software design concept to abstract major logic components of VuFind into their own entity.  This allows for a low cohesion/high coupling design.  If you understand the idea behind low cohesion and high coupling, you will have a hard time arguing against the idea.

This design has many benefits from the Open Source perspective as well - mainly to allow each major component to have their own dedicated community where development and innovation can happen much faster and much more effectively.  The VuFind community can then dedicate their effort to focusing on the interface and how the system works overall.  All underlying search logic is handled by Solr, which has its own dedicated community with people solely focused on improving indexed data searching.  As of the past few weeks, now all marc importing is handled by the SolrMarc tool and it has its own community.  Soon, all ILS interfacing will happen through Jangle, which has its own dedicated community.  So you can see how the development and innovation can build much quicker in these communities, allowing for VuFind development and innovation to happen with the VuFind software - rather than spending our time on these other components.

And since folks can belong to many communities, there can also be some "cross pollination" of ideas, etc.

Now you may ask, so why Jangle for the ILS Interactive layer.  Because as of now, Jangle is the only open source implementation of the DLF ILS-DI spec and has an established community in the same world that VuFind exists.  And it's mainly made up of Code4Libbers which is also a large population of the VuFind community.

In summary - this abstracted design allows development to happen quicker.  As to your concerns about getting up and running by Q1 2010 - there should be no concern from the angle of merging VuFind ILS Drivers to Jangle.  That will happen when Jangle is stable and ready.  I'm sure that VuFind 1.0 will not use jangle.  Maybe VuFind 1.1 or maybe 2.0 - but eventually I see the ILS Drivers abstracted to Jangle.

Does this answer your questions?

Andrew

> -----Original Message-----
> From: [hidden email] [mailto:vufind-tech-
> [hidden email]] On Behalf Of Tim McGeary
> Sent: Wednesday, July 02, 2008 3:58 PM
> To: [hidden email]
> Subject: [VuFind-Tech] Jangle: Why such an emphasis?
>
> Ok, so I'm nearly caught up on all my listserv emails while I was on
> vacation, and I have a question that I'm confused about.  There were
> two
> topics here on VUFind-Tech that I am particularly interested in (marc
> holdings and web service) and in both cases, there is a specific
> emphasis on including the Jangle project.  Including the Jangle folks
> in
> the loop is fine, but I don't understand why the sudden emphasis on it?
>
> Is Jangle all of the sudden expected to be the be-all-end-all of the
> ILS
> drivers for VUFind and other ILS-DI applications?  Please correctly me
> if I'm wrong, but so far, it just seems like yet another layer to get
> in
> between the ILS and the application we are trying to use.  If it is
> meant to be a single source for vendors to discuss, like the de facto,
> or at least first, implementation of the ILS-DI specifications
> (whatever
> those specs really end up being), I don't want to put all of our eggs
> into that basket.  Especially since SirsiDynix has been clearly
> interested in working on assisting their customers with ILS-DI issues.
>
> So before we keep throwing topics into the Jangle baskets, can we have
> a
> frank discussion about the importance and weight VUFind is putting on
> Jangle?  It has been difficult enough to work on the ILS driver code,
> get SirsiDynix's permission in writing (which has been accomplished) to
> release that API code to other SirsiDynix customers wanting to use
> VUFind, I want to be sure I understand just how this conversation with
> SD will continue and/or change based on this communities interest,
> emphasis, or dependence on Jangle.
>
> Within the specific topics Naomi brought up, MARC holdings, in some
> manner, has to be a part of the index within VUFind in the near future
> for us to be able to use VUFind in production.  To give it even more
> emphasis, we are now on a ticking clock of an end-of-life statement for
> our current OPAC.  If VUFind is to be a viable replacement, I have
> until
> Q1 of 2010 (not that far off) to have EVERYTHING SD offers in VUFind
> and
> our Unicorn/Symphony driver.  That includes user accounts, request,
> etc.
>   75% of that is not a concern of the VUFind community, but MARC
> holdings, item types (not defined in the bib record) as facets, and the
> process of doing incremental adds, updates, and deletes (export/import
> or web service) to the index are.
>
> Let's discuss.  I want to understand this better.  Thanks!  :)
>
> Cheers,
> Tim
>
> --
> Tim McGeary
> Senior Systems Specialist
> Lehigh University
> 610-758-4998
> [hidden email]
> Google Talk: timmcgeary
> Yahoo IM: timmcgeary
>
> -----------------------------------------------------------------------
> --
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Vufind-tech mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/vufind-tech

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Vufind-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vufind-tech
Reply | Threaded
Open this post in threaded view
|

Re: Jangle: Why such an emphasis?

Naomi Dushay
In reply to this post by Tim McGeary
My personal motivation in holdings / web services discussions:

I want to get the information into vufind.
I'm happy to try to use appropriate models from current efforts.
I'm happy to help lobby for general, re-usable pieces (abstracted web  
service?  xml schemas?  vufind pieces?  etc) in this process ... as  
time permits.

I was glad to get Andrew's steer to the efforts of Jangle and the  
current development of the DLF's ILS Discovery Interface work.  I will  
build on what I can, and incorporate what I can.  For example, there  
are some existing xml formats I didn't know about that might be  
appropriate for the holdings information.

But fundamentally, like Tim, what's most important to my employer is  
delivering the desired services in the desired timeframe.   I will  
gladly share whatever code we write with the community.

- Naomi

On Jul 2, 2008, at 12:57 PM, Tim McGeary wrote:

> Ok, so I'm nearly caught up on all my listserv emails while I was on
> vacation, and I have a question that I'm confused about.  There were  
> two
> topics here on VUFind-Tech that I am particularly interested in (marc
> holdings and web service) and in both cases, there is a specific
> emphasis on including the Jangle project.  Including the Jangle  
> folks in
> the loop is fine, but I don't understand why the sudden emphasis on  
> it?
>
> Is Jangle all of the sudden expected to be the be-all-end-all of the  
> ILS
> drivers for VUFind and other ILS-DI applications?  Please correctly me
> if I'm wrong, but so far, it just seems like yet another layer to  
> get in
> between the ILS and the application we are trying to use.  If it is
> meant to be a single source for vendors to discuss, like the de facto,
> or at least first, implementation of the ILS-DI specifications  
> (whatever
> those specs really end up being), I don't want to put all of our eggs
> into that basket.  Especially since SirsiDynix has been clearly
> interested in working on assisting their customers with ILS-DI issues.
>
> So before we keep throwing topics into the Jangle baskets, can we  
> have a
> frank discussion about the importance and weight VUFind is putting on
> Jangle?  It has been difficult enough to work on the ILS driver code,
> get SirsiDynix's permission in writing (which has been accomplished)  
> to
> release that API code to other SirsiDynix customers wanting to use
> VUFind, I want to be sure I understand just how this conversation with
> SD will continue and/or change based on this communities interest,
> emphasis, or dependence on Jangle.
>
> Within the specific topics Naomi brought up, MARC holdings, in some
> manner, has to be a part of the index within VUFind in the near future
> for us to be able to use VUFind in production.  To give it even more
> emphasis, we are now on a ticking clock of an end-of-life statement  
> for
> our current OPAC.  If VUFind is to be a viable replacement, I have  
> until
> Q1 of 2010 (not that far off) to have EVERYTHING SD offers in VUFind  
> and
> our Unicorn/Symphony driver.  That includes user accounts, request,  
> etc.
>  75% of that is not a concern of the VUFind community, but MARC
> holdings, item types (not defined in the bib record) as facets, and  
> the
> process of doing incremental adds, updates, and deletes (export/import
> or web service) to the index are.
>
> Let's discuss.  I want to understand this better.  Thanks!  :)
>
> Cheers,
> Tim
>
> --
> Tim McGeary
> Senior Systems Specialist
> Lehigh University
> 610-758-4998
> [hidden email]
> Google Talk: timmcgeary
> Yahoo IM: timmcgeary
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Vufind-tech mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/vufind-tech

Naomi Dushay
[hidden email]




-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Vufind-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vufind-tech
Reply | Threaded
Open this post in threaded view
|

Re: Jangle: Why such an emphasis?

Tim McGeary
In reply to this post by Andrew Nagy-2
Philosophically, yes, the concept of abstracting makes sense.  But
functionally, technically, and practically, I don't yet buy into Jangle
as the dedicated protocol for this, and quite frankly I don't know if it
is needed or actually possible.  Here are some reasons.

1.) There is an assumption that the Atom Publishing Protocol will be an
acceptable protocol.  That is not a safe assumption.

2.) There is an assumption that ILS vendors would rather work with
developers of Jangle, et al apps that pop-up rather than their own
customers who are trying to use a DI, like VUFind.  That is a VERY
unsafe assumption.

SirsiDynix (SD), for example, has already made significant movement
towards assisting us in making VUFind feasible and practical to the
SirsiDynix community.  They have done this in the face of VUFind being a
direct competitor to their own next-generation DI.  Why?  Because they
know that they cannot sustain development of DI applications, and they
are really in the ILS business.  They want to show that their ILS is
stronger and more flexible than all the others, and if helping their
customers use other DI apps or modular type of extras keeps their
customers invested in SD's ILS, then we both win.

3.) What is Jangle actually building on right now?  The specification of
the ILS-DI task force means absolutely nothing without vendors creating
an API within the specification.  And no vendor has made such an effort.
  SirsiDynix, the biggest vendor, and maybe not coincidentally the one
that has the most open API, is looking at this as a way to help their
customers, not necessarily help developers of DI.  Creating an ILS-DI
API and releasing that publicly are two entirely different things.

So what is it that we are expected to share with Jangle right now?  The
specific output format of our current API?  No, we can't do that without
violating our NDA.  Same with any expectation that we submit code for
connections to our ILS.

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?

Tim

Tim McGeary
Senior Systems Specialist
Lehigh University
610-758-4998
[hidden email]
Google Talk: timmcgeary
Yahoo IM: timmcgeary

Andrew Nagy wrote:

> There are many reasons for abstracting the ILS Drivers to Jangle.
> However, I would say that the main argument is from a software design
> concept to abstract major logic components of VuFind into their own
> entity.  This allows for a low cohesion/high coupling design.  If you
> understand the idea behind low cohesion and high coupling, you will
> have a hard time arguing against the idea.
>
> This design has many benefits from the Open Source perspective as
> well - mainly to allow each major component to have their own
> dedicated community where development and innovation can happen much
> faster and much more effectively.  The VuFind community can then
> dedicate their effort to focusing on the interface and how the system
> works overall.  All underlying search logic is handled by Solr, which
> has its own dedicated community with people solely focused on
> improving indexed data searching.  As of the past few weeks, now all
> marc importing is handled by the SolrMarc tool and it has its own
> community.  Soon, all ILS interfacing will happen through Jangle,
> which has its own dedicated community.  So you can see how the
> development and innovation can build much quicker in these
> communities, allowing for VuFind development and innovation to happen
> with the VuFind software - rather than spending our time on these
> other components.
>
> And since folks can belong to many communities, there can also be
> some "cross pollination" of ideas, etc.
>
> Now you may ask, so why Jangle for the ILS Interactive layer.
> Because as of now, Jangle is the only open source implementation of
> the DLF ILS-DI spec and has an established community in the same
> world that VuFind exists.  And it's mainly made up of Code4Libbers
> which is also a large population of the VuFind community.
>
> In summary - this abstracted design allows development to happen
> quicker.  As to your concerns about getting up and running by Q1 2010
> - there should be no concern from the angle of merging VuFind ILS
> Drivers to Jangle.  That will happen when Jangle is stable and ready.
> I'm sure that VuFind 1.0 will not use jangle.  Maybe VuFind 1.1 or
> maybe 2.0 - but eventually I see the ILS Drivers abstracted to
> Jangle.
>
> Does this answer your questions?
>
> Andrew
>
>> -----Original Message----- From:
>> [hidden email] [mailto:vufind-tech-
>> [hidden email]] On Behalf Of Tim McGeary Sent:
>> Wednesday, July 02, 2008 3:58 PM To:
>> [hidden email] Subject: [VuFind-Tech] Jangle:
>> Why such an emphasis?
>>
>> Ok, so I'm nearly caught up on all my listserv emails while I was
>> on vacation, and I have a question that I'm confused about.  There
>> were two topics here on VUFind-Tech that I am particularly
>> interested in (marc holdings and web service) and in both cases,
>> there is a specific emphasis on including the Jangle project.
>> Including the Jangle folks in the loop is fine, but I don't
>> understand why the sudden emphasis on it?
>>
>> Is Jangle all of the sudden expected to be the be-all-end-all of
>> the ILS drivers for VUFind and other ILS-DI applications?  Please
>> correctly me if I'm wrong, but so far, it just seems like yet
>> another layer to get in between the ILS and the application we are
>> trying to use.  If it is meant to be a single source for vendors to
>> discuss, like the de facto, or at least first, implementation of
>> the ILS-DI specifications (whatever those specs really end up
>> being), I don't want to put all of our eggs into that basket.
>> Especially since SirsiDynix has been clearly interested in working
>> on assisting their customers with ILS-DI issues.
>>
>> So before we keep throwing topics into the Jangle baskets, can we
>> have a frank discussion about the importance and weight VUFind is
>> putting on Jangle?  It has been difficult enough to work on the ILS
>> driver code, get SirsiDynix's permission in writing (which has been
>> accomplished) to release that API code to other SirsiDynix
>> customers wanting to use VUFind, I want to be sure I understand
>> just how this conversation with SD will continue and/or change
>> based on this communities interest, emphasis, or dependence on
>> Jangle.
>>
>> Within the specific topics Naomi brought up, MARC holdings, in some
>>  manner, has to be a part of the index within VUFind in the near
>> future for us to be able to use VUFind in production.  To give it
>> even more emphasis, we are now on a ticking clock of an end-of-life
>> statement for our current OPAC.  If VUFind is to be a viable
>> replacement, I have until Q1 of 2010 (not that far off) to have
>> EVERYTHING SD offers in VUFind and our Unicorn/Symphony driver.
>> That includes user accounts, request, etc. 75% of that is not a
>> concern of the VUFind community, but MARC holdings, item types (not
>> defined in the bib record) as facets, and the process of doing
>> incremental adds, updates, and deletes (export/import or web
>> service) to the index are.
>>
>> Let's discuss.  I want to understand this better.  Thanks!  :)
>>
>> Cheers, Tim
>>
>> -- Tim McGeary Senior Systems Specialist Lehigh University
>> 610-758-4998 [hidden email] Google Talk: timmcgeary Yahoo
>> IM: timmcgeary
>>
>> -----------------------------------------------------------------------
>>  -- Sponsored by: SourceForge.net Community Choice Awards: VOTE
>> NOW! Studies have shown that voting for your favorite open source
>> project, along with a healthy diet, reduces your potential for
>> chronic lameness and boredom. Vote Now at
>> http://www.sourceforge.net/community/cca08 
>> _______________________________________________ Vufind-tech mailing
>> list [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/vufind-tech
>
> -------------------------------------------------------------------------
>  Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
>  along with a healthy diet, reduces your potential for chronic
> lameness and boredom. Vote Now at
> http://www.sourceforge.net/community/cca08 
> _______________________________________________ Vufind-tech mailing
> list [hidden email]
> https://lists.sourceforge.net/lists/listinfo/vufind-tech
>

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Vufind-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vufind-tech
Reply | Threaded
Open this post in threaded view
|

Re: Jangle: Why such an emphasis?

Andrew Nagy-2
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.  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.

> 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.

Andrew

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Vufind-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vufind-tech
Reply | Threaded
Open this post in threaded view
|

Re: Jangle: Why such an emphasis?

Tim McGeary
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
[hidden email]
Google Talk: timmcgeary
Yahoo IM: timmcgeary

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Vufind-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vufind-tech
Reply | Threaded
Open this post in threaded view
|

Re: Jangle: Why such an emphasis?

wally grotophorst
I'll toss in a couple of thoughts on this Jangle discussion (realizing I
may well have missed the point):
 
1) There probably isn't much incentive for a vendor to become compliant
with VuFind or Jangle.   In my experience with library automation
vendors they don't get too excited about helping support something that
could cost them (or their guild) current or future sales.   If you're
able to remember how Z39.50 support trickled into ILS products, you'll
agree with me that library vendors seem to develop support for standards
only when most of their current and prospective customers demand it, not
the other way around.

2) Jangle is associated with a particular library vendor (Talis) and
that's yet another reason other ILS vendors might not rush to support it.

3) There aren't 50 or 60 ILS systems out there so while a single, common
connector would be great, not having one isn't a showstopper.

4)  Why not keep the individual connector logic in VuFind and just add
one additional connector (Jangle).  Then if you can use it great, if you
can't, you have another option while we  pushe Jangle (or the next good
middleware idea) adoption forward.

--Wally

Wally Grotophorst
Associate University Librarian
Digital Programs and Systems
University Libraries
George Mason University
Fairfax, Virginia 22030
(703) 993-9005





> 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
> [hidden email]
> Google Talk: timmcgeary
> Yahoo IM: timmcgeary
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Vufind-tech mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/vufind-tech
>  


-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Vufind-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vufind-tech
Reply | Threaded
Open this post in threaded view
|

Re: Jangle: Why such an emphasis?

Andrew Nagy-2
In reply to this post by Tim McGeary
> 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.

I don't think I am explaining myself well here. The only thing that would really change in the adoption of Jangle is how VuFind interacts with the ILS driver itself.  Right now, the ILS driver is a PHP class that is loaded directly into VuFind.  With Jangle, VuFind would talk to it much like how it talks to Solr now - via HTTP.  Jangle would then have a series of ILS drivers loaded for each ILS that is not ILS-DI compatible.  For those that are ILS-DI compatible, Jangle would use the ILS-DI driver.

>
> 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.)

VuFind will continue to be ILS agnostic and Jangle will only help it be better. I don't think you clearly understand the uses and implications of Jangle and how it would work within VuFind.  Im probably not explaining myself very clearly.  I really don't see much change happening to VuFind in how the ILS Drivers work.  We are basically just making the ILS Drivers better by abstracting them into another community.

And don't forget, Jangle is open source - so we can tweak it if it doesn't quite fit the needs of VuFind.

Im struggling for a way to better explain myself - but I feel confident that Jangle will only help the progress of VuFind and not be a hindrance.

Here is some more information on how this might work:
http://code.google.com/p/jangle/wiki/ApproachesToWritingAConnector

Andrew

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Vufind-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vufind-tech
Reply | Threaded
Open this post in threaded view
|

Re: Jangle: Why such an emphasis?

Andrew Nagy-2
In reply to this post by wally grotophorst
> 4)  Why not keep the individual connector logic in VuFind and just add
> one additional connector (Jangle).  Then if you can use it great, if
> you
> can't, you have another option while we  pushe Jangle (or the next good
> middleware idea) adoption forward.
>

This is a perfectly good option - however by moving our ILS Drivers into the Jangle community, that allows other users of other DI systems to contribute to the source code, only growing the community of developers even larger.

Andrew

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Vufind-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vufind-tech
Reply | Threaded
Open this post in threaded view
|

Re: Jangle: Why such an emphasis?

Tim McGeary
Andrew Nagy wrote:

>> 4)  Why not keep the individual connector logic in VuFind and just
>> add one additional connector (Jangle).  Then if you can use it
>> great, if you can't, you have another option while we  pushe Jangle
>> (or the next good middleware idea) adoption forward.
>>
>
> This is a perfectly good option - however by moving our ILS Drivers
> into the Jangle community, that allows other users of other DI
> systems to contribute to the source code, only growing the community
> of developers even larger.
>

Moving our ILS Drivers into the Jangle community is a perfect way to be
sued!  We will never be able to release our ILS drivers to any community
outside of the SirsiDynix Users Group.  Is that seriously what Jangle
expects?

We already have in writing what we are allowed to do with our current
read-only VUFind driver proof-of-concept.  And that is protecting it as
a group to ensure that only SirsiDynix Symphony ILS libraries can see it.

The future read-write driver will only be made available to the
SirsiDynix API community.



Tim McGeary
Senior Systems Specialist
Lehigh University
610-758-4998
[hidden email]
Google Talk: timmcgeary
Yahoo IM: timmcgeary

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Vufind-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vufind-tech
Reply | Threaded
Open this post in threaded view
|

Re: Jangle: Why such an emphasis?

Andrew Nagy-2
So instead of VuFind users only being able to take advantage of the driver, now all Jangle users at SD Libraries can take advantage of the communication layer.  Seems like SD would be in favor of that - allowing more of their clients to have access to more technologies.

I still don't see the down side, sorry.

Andrew

> -----Original Message-----
> From: Tim McGeary [mailto:[hidden email]]
> Sent: Thursday, July 03, 2008 1:18 PM
> To: Andrew Nagy
> Cc: wally grotophorst; [hidden email]
> Subject: Re: [VuFind-Tech] Jangle: Why such an emphasis?
>
> Andrew Nagy wrote:
> >> 4)  Why not keep the individual connector logic in VuFind and just
> >> add one additional connector (Jangle).  Then if you can use it
> >> great, if you can't, you have another option while we  pushe Jangle
> >> (or the next good middleware idea) adoption forward.
> >>
> >
> > This is a perfectly good option - however by moving our ILS Drivers
> > into the Jangle community, that allows other users of other DI
> > systems to contribute to the source code, only growing the community
> > of developers even larger.
> >
>
> Moving our ILS Drivers into the Jangle community is a perfect way to be
> sued!  We will never be able to release our ILS drivers to any
> community
> outside of the SirsiDynix Users Group.  Is that seriously what Jangle
> expects?
>
> We already have in writing what we are allowed to do with our current
> read-only VUFind driver proof-of-concept.  And that is protecting it as
> a group to ensure that only SirsiDynix Symphony ILS libraries can see
> it.
>
> The future read-write driver will only be made available to the
> SirsiDynix API community.
>
>
>
> Tim McGeary
> Senior Systems Specialist
> Lehigh University
> 610-758-4998
> [hidden email]
> Google Talk: timmcgeary
> Yahoo IM: timmcgeary

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Vufind-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vufind-tech
Reply | Threaded
Open this post in threaded view
|

Re: Jangle: Why such an emphasis?

Joel Timothy Norman, Mr
In reply to this post by Tim McGeary
Hi,

I have been reading this discussion and have somes questions:

Performance?
      How will this effect the response time of vufind?  Another layer of HTTP Calls/Request could potentially slow down the entire system, even on the localhost.

Maintainable?  
    This seems like another layer of code that someone has to keep their eye on.
     When I leave the library,  our vufind installation could possibly go stale, since this project keeps getting larger, more complex, harder to manage.

Legal?
   Last thing that we need at our university is legal issues.  I think it is very important to  respect the   copyrights, patents, confidentiality agreements that we have with our ILS Vendors.  We all love VUFIND, but each library NEEDS an ILS.  Don't let our legal department chose what is good for the library!! :) :) :)

My 2 Cents,
Joel


Joel Norman

----- Original Message -----
From: Andrew Nagy <[hidden email]>
Date: Thursday, July 3, 2008 2:54 pm
Subject: Re: [VuFind-Tech] Jangle: Why such an emphasis?

> So instead of VuFind users only being able to take advantage of the
> driver, now all Jangle users at SD Libraries can take advantage of
> the communication layer.  Seems like SD would be in favor of that -
> allowing more of their clients to have access to more technologies.
>
> I still don't see the down side, sorry.
>
> Andrew
>
> > -----Original Message-----
> > From: Tim McGeary [[hidden email]]
> > Sent: Thursday, July 03, 2008 1:18 PM
> > To: Andrew Nagy
> > Cc: wally grotophorst; [hidden email]
> > Subject: Re: [VuFind-Tech] Jangle: Why such an emphasis?
> >
> > Andrew Nagy wrote:
> > >> 4)  Why not keep the individual connector logic in VuFind and
> just> >> add one additional connector (Jangle).  Then if you can
> use it
> > >> great, if you can't, you have another option while we  pushe
> Jangle> >> (or the next good middleware idea) adoption forward.
> > >>
> > >
> > > This is a perfectly good option - however by moving our ILS
> Drivers> > into the Jangle community, that allows other users of
> other DI
> > > systems to contribute to the source code, only growing the
> community> > of developers even larger.
> > >
> >
> > Moving our ILS Drivers into the Jangle community is a perfect way
> to be
> > sued!  We will never be able to release our ILS drivers to any
> > community
> > outside of the SirsiDynix Users Group.  Is that seriously what
> Jangle> expects?
> >
> > We already have in writing what we are allowed to do with our
> current> read-only VUFind driver proof-of-concept.  And that is
> protecting it as
> > a group to ensure that only SirsiDynix Symphony ILS libraries can
> see> it.
> >
> > The future read-write driver will only be made available to the
> > SirsiDynix API community.
> >
> >
> >
> > Tim McGeary
> > Senior Systems Specialist
> > Lehigh University
> > 610-758-4998
> > [hidden email]
> > Google Talk: timmcgeary
> > Yahoo IM: timmcgeary
>
> --------------------------------------------------------------------
> -----
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Vufind-tech mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/vufind-tech
>


-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Vufind-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vufind-tech
Reply | Threaded
Open this post in threaded view
|

Re: Jangle: Why such an emphasis?

Naomi Dushay
In reply to this post by Andrew Nagy-2
I think we're mostly in agreement here -- just looking at different  
parts of the elephant.  Bottom line:  Andrew is talking about ADDING  
this nifty new capability and is hopeful that the ILS vendors will  
comply.  Vufind is not going to remove the current way we hook to the  
ILS for holdings.  Tim is looking for stability in functionality  
required for Vufind and in stability in his relationship with SD to  
keep providing the functionality needed for vufind.

I *may* be speaking for all of us if I say that we techies are in  
favor of open source, and a nifty abstract layer (like SOLR has -  
using ReST (urls in, xml out).  Besides being more vendor-neutral, it  
means we techies can have more common knowledge to share.  (think  
marc21 format.  think solr.  think marcxml)  That's exactly what I was  
hoping for in my recent postings about holdings and web services.

I think Tim's concern is it might slow down his local development  
effort if Sirsi balks in some way, now or in the future.  And what if  
the current way to hook to holdings becomes deprecated soon?   (by SD,  
or even vufind - though that's been laid to rest)

My experience has been:
---
If it's more work for the ILS vendor, and it won't bring them  
additional revenue ... then they're generally not interested.
If it's viewed in any way as giving up current or potential revenue  
stream ... then they're generally not interested. (e.g. can they make $
$ b/c the SD site has to have the API software and then the expensive  
API training in order to do anything beyond the basics?)

As we all know, many excellent standards are never adopted broadly  
enough to fulfill their promise.  But I'd be glad if Jangle WAS adopted.

- Naomi

On Jul 3, 2008, at 11:54 AM, Andrew Nagy wrote:

> So instead of VuFind users only being able to take advantage of the  
> driver, now all Jangle users at SD Libraries can take advantage of  
> the communication layer.  Seems like SD would be in favor of that -  
> allowing more of their clients to have access to more technologies.
>
> I still don't see the down side, sorry.
>
> Andrew
>
>> -----Original Message-----
>> From: Tim McGeary [mailto:[hidden email]]
>> Sent: Thursday, July 03, 2008 1:18 PM
>> To: Andrew Nagy
>> Cc: wally grotophorst; [hidden email]
>> Subject: Re: [VuFind-Tech] Jangle: Why such an emphasis?
>>
>> Andrew Nagy wrote:
>>>> 4)  Why not keep the individual connector logic in VuFind and just
>>>> add one additional connector (Jangle).  Then if you can use it
>>>> great, if you can't, you have another option while we  pushe Jangle
>>>> (or the next good middleware idea) adoption forward.
>>>>
>>>
>>> This is a perfectly good option - however by moving our ILS Drivers
>>> into the Jangle community, that allows other users of other DI
>>> systems to contribute to the source code, only growing the community
>>> of developers even larger.
>>>
>>
>> Moving our ILS Drivers into the Jangle community is a perfect way  
>> to be
>> sued!  We will never be able to release our ILS drivers to any
>> community
>> outside of the SirsiDynix Users Group.  Is that seriously what Jangle
>> expects?
>>
>> We already have in writing what we are allowed to do with our current
>> read-only VUFind driver proof-of-concept.  And that is protecting  
>> it as
>> a group to ensure that only SirsiDynix Symphony ILS libraries can see
>> it.
>>
>> The future read-write driver will only be made available to the
>> SirsiDynix API community.
>>
>>
>>
>> Tim McGeary
>> Senior Systems Specialist
>> Lehigh University
>> 610-758-4998
>> [hidden email]
>> Google Talk: timmcgeary
>> Yahoo IM: timmcgeary
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Vufind-tech mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/vufind-tech

Naomi Dushay
[hidden email]




-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Vufind-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vufind-tech
Reply | Threaded
Open this post in threaded view
|

Re: Jangle: Why such an emphasis?

James Farrugia
In reply to this post by Tim McGeary
Hi,

I think that we Unicorn/VuFind folk aren't quite getting what Jangle is all about, why it's better than what we're doing now in VuFind, and what the implications are for us of VuFind+Jangle down the road.

First off, full disclosure:  I'm working with Ross Singer on his code4lib paper about Jangle that is due on Friday the 18th (gulp :-).

I volunteered to do what I can to get proof-of-concept code working with Unicorn and Jangle. We had some small successes
over the weekend, and right now it looks as though this'll happen by the 18th. I'm hoping that through this collaboration,
Ross and I can share our understanding of the what, why, and wherefore about Jangle. This'll happen over time, but
right now I want to follow up on some of Tim's and Andrew's discussions. (I had to pick one email to include and I chose this one; apologies in advance if I misrepresent some of the views presented.)

As things stand now, there's this Unicorn.php driver in VuFind that talks to a back-end Unicorn server script to return item info for the getHolding and getHoldings functions. These two pieces (driver and Unicorn server script) are what we've put our time into and what we plan on continuing to develop with, say, functionality for MARC Holdings and user account stuff, at least.
So far, SirsiDynix is ok with what we're doing with "read-only" API stuff on the Unicorn server, and they've given us
permission to share that code within the broader Unicorn/VuFind group. Once we get to user account info, though, that'll
involve "read-write" APIs on the Unicorn end, and I don't think we've yet worked out with Sirsi how to share this code with the Unicorn/Vufind group.

When Andrew mentions that he sees it as a clear decision to utilize Jangle as the ILS Layer for VuFind
just as we use Solr for the searching layer, it makes me nervous, for a couple of reasons.

One, I still don't get Jangle, and even supposing it's the perfect way forward for VuFind, I as a Unicorn/VuFind person have a lot of concerns that haven't yet been addressed. Tim mentioned some, and let me echo some of them and add a few perhaps.

1. The Unicorn/VuFind people have invested a lot of time in doing things a la Unicorn.php and vufind.pl (the driver and corresponding backend Unicorn server script), and to learn that there will be a new way of abstracting drivers into Jangle
just makes me nervous, since it seems like yet more overhead to learn and it will amount to switching horses in midstream.

2. Jangle may be a great way to do what it proposes to do, but most of us I think are still in the dark about what it proposes
to do and why it may indeed be great. What's it all about and why is it wonderful?  More to the point, why is it the right
way for VuFind to go with its drivers? What functionality will be gained? What will be lost?  Also, VuFind is much more
developed than Jangle is right now, and it's hard to consider moving to a platform that is less developed.

3. Jangle uses the Atom Publishing Protocol. Why?  Won't that severely limit the bibliographic metadata from a MARC bib record, for instance?

4. Jangle uses JSON (not XML), but our Unicorn.php and vufind.pl use XML, so there's more overhead (and, ..., Ruby? ) to learn if we go the Jangle route.

5. What specific kind of changes would Unicorn/VuFind folks need to make to the Unicorn driver and back-end server script
to create a Jangle connector, and how exactly would such a connector work with the Jangle core?

6. SirsiDynix is on board with the Unicorn/VuFind group doing things as we've been doing them. It's an open question whether they'd be on board if we migrated our drivers to Jangle.

7. How does VuFind need to be re-architected to migrate VuFind drivers to Jangle? By when will that happen?

8. The ILS-DI: I won't go there. :-)

We probably can't resolve all this on the list, but if you can add any ideas or concerns, that would help Ross and me a lot
in our explanations.

Thanks,

Jim


>>> On 7/3/2008 at 11:21 AM, Tim McGeary <[hidden email]> wrote:
> 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
> [hidden email]
> Google Talk: timmcgeary
> Yahoo IM: timmcgeary
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08 
> _______________________________________________
> Vufind-tech mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/vufind-tech

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Vufind-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vufind-tech
Reply | Threaded
Open this post in threaded view
|

Re: Jangle: Why such an emphasis?

Andrew Nagy-2
I think I am severely failing to explain myself :) ... I will try one more time.

>
> 1. The Unicorn/VuFind people have invested a lot of time in doing
> things a la Unicorn.php and vufind.pl (the driver and corresponding
> backend Unicorn server script), and to learn that there will be a new
> way of abstracting drivers into Jangle
> just makes me nervous, since it seems like yet more overhead to learn
> and it will amount to switching horses in midstream.

Nothing says that you can't continue to use your Unicorn.php/vufind.pl solution.  VuFind is after all open source and you can do whatever you want with it.

Jangle gives us a platform to standardize this communication.  The Unicorn guys are building this great client/server style app ... but what about all of the other ILS systems that need similar communication.  If we have a standardized communication layer, it would make future development a lot easier.

>
> 2. Jangle may be a great way to do what it proposes to do, but most of
> us I think are still in the dark about what it proposes
> to do and why it may indeed be great. What's it all about and why is it
> wonderful?  More to the point, why is it the right
> way for VuFind to go with its drivers? What functionality will be
> gained? What will be lost?  Also, VuFind is much more
> developed than Jangle is right now, and it's hard to consider moving to
> a platform that is less developed.

That would just be a really dumb decision, and I don't think anyone is proposing that.
I have mentioned numerous reason for what Jangle can provide us, so I won't go into that again.  Read the other emails for more details.

>
> 3. Jangle uses the Atom Publishing Protocol. Why?  Won't that severely
> limit the bibliographic metadata from a MARC bib record, for instance?

There are 2 ways of communication.  The first is from the DI to Jangle.  The second is from Jangle to the ILS.  I believe ATOM is proposed to be used from the DI to Jangle communication.  None of the ILSs will need to be or be expected to speak ATOM.

>
> 4. Jangle uses JSON (not XML), but our Unicorn.php and vufind.pl use
> XML, so there's more overhead (and, ..., Ruby? ) to learn if we go the
> Jangle route.

Yeah - I don't like the idea of introducing Ruby into the mix.  Maybe we could build PHangle?  I think porting jangle to PHP might be an interesting solution - though I haven't really thought that far yet.
But JSON vs. XML is neither here nor there.  The difference between the 2 is negligible.

>
> 5. What specific kind of changes would Unicorn/VuFind folks need to
> make to the Unicorn driver and back-end server script
> to create a Jangle connector, and how exactly would such a connector
> work with the Jangle core?

I would hope nothing.  If we adopt jangle in ruby, then I would assume we would need to port to ruby - unless ruby can understand php.
But then again, I b ring up the idea of PHangle - and then nothing would need to be done.

>
> 6. SirsiDynix is on board with the Unicorn/VuFind group doing things as
> we've been doing them. It's an open question whether they'd be on board
> if we migrated our drivers to Jangle.

The drivers would be the same - it's just whether Jangle reads the response from the driver or vufind reads the response.

>
> 7. How does VuFind need to be re-architected to migrate VuFind drivers
> to Jangle? By when will that happen?

Dunno - haven't gotten that far yet.  I would that we would just switch from Loading the various ILS drivers over to loading a Jangle driver.  I would assume it would be very simple and very little code change.  Famous last words I'm sure.

>
> 8. The ILS-DI: I won't go there. :-)

Yeah - well Jangle will speak ILS-DI as one method of communication - however I doubt anyone will ever end up using this.  My guess is 90% of ILS interaction will go through ILS Drivers.

>
> We probably can't resolve all this on the list, but if you can add any
> ideas or concerns, that would help Ross and me a lot
> in our explanations.
>

Well as far as I can tell - everything seems to be positive from my angle.  The only negatives I see are implementing Jangle in Ruby - when the VuFind community has been developing its ILS Drivers in PHP.  Other than that, it seems like a great solution to me.


Andrew


-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Vufind-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vufind-tech
Reply | Threaded
Open this post in threaded view
|

Re: Jangle: Why such an emphasis?

Tim McGeary
Andrew Nagy wrote:
> I think I am severely failing to explain myself :) ... I will try one
>  more time.

Maybe we are, too.

>> 1. The Unicorn/VuFind people have invested a lot of time in doing
>> things a la Unicorn.php and vufind.pl (the driver and corresponding
>>  backend Unicorn server script), and to learn that there will be a
>>  new way of abstracting drivers into Jangle just makes me nervous,
>>  since it seems like yet more overhead to learn and it will amount
>>  to switching horses in midstream.
>
> Nothing says that you can't continue to use your
> Unicorn.php/vufind.pl solution.  VuFind is after all open source and
>  you can do whatever you want with it.

So are you saying that VUFind will support BOTH Jangle as an ILS
interactive layer AND the ILS Drivers as they stand now?  If not, then
what you saying is that VUFind will fork, correct?

> Jangle gives us a platform to standardize this communication.  The
> Unicorn guys are building this great client/server style app ... but
>  what about all of the other ILS systems that need similar
> communication.  If we have a standardized communication layer, it
> would make future development a lot easier.

I don't see how this is different than what you have built into VUFind.
  You are asking ILS drivers to communicate to VUFind is a specific way.
  It's up to those in each ILS community to come up with a driver to
communicate with VUFind in that specific way.

Jangle is seeking the very same thing, except using Atom and Ruby.

>> 2. Jangle may be a great way to do what it proposes to do, but most
>>  of us I think are still in the dark about what it proposes to do
>> and why it may indeed be great. What's it all about and why is it
>> wonderful?  More to the point, why is it the right way for VuFind
>> to go with its drivers? What functionality will be gained? What
>> will be lost?  Also, VuFind is much more developed than Jangle is
>> right now, and it's hard to consider moving to a platform that is
>> less developed.
>
> That would just be a really dumb decision, and I don't think anyone
> is proposing that. I have mentioned numerous reason for what Jangle
> can provide us, so I won't go into that again.  Read the other emails
>  for more details.

Actually, Andrew, with all due respect, you only mentioned a few reasons
at a high level mosty about how Jangle abstracts the ILS interaction to
another component like SOLR.  Quite frankly, that isn't a good enough
reason yet because Jangle, for all intents and purposes, is still
vaporware.

What we are seeking are very specific details.  We are elbow-deep in our
efforts to make VUFind usable for SirsiDynix Unicorn/Symphony users: a
large (actually THE largest) available ILS community out there.  And
more specifically, we want to stay at the same level with VUFind and not
have to fork off because of this issue.

I just looked back at this discussion and here's what you mentioned so
far.  I'll comment underneath to keep context context.

> 1.) Abstracted design - low cohesion/high coupling

Nothing wrong with that.

> 2.) "Jangle is the only open source implementation of the DLF ILS-DI
> spec and has an established community in the same world that VuFind
> exists."

Ditto - nothing wrong with this.

> 3.) "Right now, the ILS driver is a PHP class that is loaded directly
>  into VuFind.  With Jangle, VuFind would talk to it much like how it
> talks to Solr now - via HTTP.  Jangle would then have a series of ILS
>  drivers loaded for each ILS that is not ILS-DI compatible.  For
> those that are ILS-DI compatible, Jangle would use the ILS-DI
> driver."

Problem #1:  Jangle won't be able to have a series of ILS drivers
loaded.  That would be in major violation of our ILS non-disclosure
agreements.  It is foolish to think otherwise.  Part b of this is that
we have already come to a written agreement with our ILS to release our
VuFind ILS driver to our ILS community for a specific product.

Problem #2:  Again, this is no different than the process of building
drivers for VuFind, except that we have already bought into VuFind as a
solution for a DI, but we have no idea what realistic future Jangle has.

Side note because you mention this later: If you, as the lead of VUFind,
are saying to us that Jangle is going to be the only supported
interactive ILS-DI layer, yet then throw in a possibility of havinv to
fork Jangle into PHP in order to make that work, how do I go to my
decision makers and confident say "VuFind the discovery interface we
will move to next and it will work long term"???  I really can't,
because neither you or I can't realistically answer that.

So why add this level of ambiguity to an otherwise remarkable development?


> 4.) "by moving our ILS Drivers into the Jangle community, that allows
>  other users of other DI systems to contribute to the source code,
> only growing the community of developers even larger."

See Problem #1 above.  If this is going to be successful, Jangle will
have to fork N times where N is the # of proprietary ILS products that
will allow their user community to share drivers amongst each other.

> 5.) "Jangle gives us a platform to standardize this communication.
> The Unicorn guys are building this great client/server style app ...
> but what about all of the other ILS systems that need similar
> communication.  If we have a standardized communication layer, it
> would make future development a lot easier."

What expectation is out that that other ILS systems communicate in the
same way?  From having experience with 2 of the 4 major proprietary
systems, I can venture a safe guess that none of them have anywhere
close to communicate methods similar with exception of maybe dumping out
their bibliographic records.  SirsiDynix's API is unlike any other system.

 From what I am gathering about the ILS-DI, all you need to do is setup
VUFind to accept communication from that point of view.  You don't need
to require Jangle.  As long as we, as ILS driver developers, communicate
to VUFind as you require, you should not care how we do it.

>> 3. Jangle uses the Atom Publishing Protocol. Why?  Won't that
>> severely limit the bibliographic metadata from a MARC bib record,
>> for instance?
>
> There are 2 ways of communication.  The first is from the DI to
> Jangle.  The second is from Jangle to the ILS.  I believe ATOM is
> proposed to be used from the DI to Jangle communication.  None of the
>  ILSs will need to be or be expected to speak ATOM.
>
>> 4. Jangle uses JSON (not XML), but our Unicorn.php and vufind.pl
>> use XML, so there's more overhead (and, ..., Ruby? ) to learn if we
>>  go the Jangle route.
>
> Yeah - I don't like the idea of introducing Ruby into the mix.  Maybe
>  we could build PHangle?  I think porting jangle to PHP might be an
> interesting solution - though I haven't really thought that far yet.
> But JSON vs. XML is neither here nor there.  The difference between
> the 2 is negligible.

If you don't like introducing Ruby in the mix, then why are you?

>> 5. What specific kind of changes would Unicorn/VuFind folks need to
>>  make to the Unicorn driver and back-end server script to create a
>>  Jangle connector, and how exactly would such a connector work with
>>  the Jangle core?
>
> I would hope nothing.  If we adopt jangle in ruby, then I would
> assume we would need to port to ruby - unless ruby can understand
> php. But then again, I b ring up the idea of PHangle - and then
> nothing would need to be done.

This is exactly my fear.  This quite possible requires a complete
re-write of the drivers.  What if this is a deal breaker to those who
are using VUFind within the existing driver system and aren't able to
support Ruby?  Can we expect them to just hope PHangle will become
reality instead?  I can't.

>> 6. SirsiDynix is on board with the Unicorn/VuFind group doing
>> things as we've been doing them. It's an open question whether
>> they'd be on board if we migrated our drivers to Jangle.
>
> The drivers would be the same - it's just whether Jangle reads the
> response from the driver or vufind reads the response.

No - you just said up above that the drivers wouldn't be the same, but
that they'd have to be ported to Ruby or possibly PHangle.

>> 7. How does VuFind need to be re-architected to migrate VuFind
>> drivers to Jangle? By when will that happen?
>
> Dunno - haven't gotten that far yet.  I would that we would just
> switch from Loading the various ILS drivers over to loading a Jangle
>  driver.  I would assume it would be very simple and very little code
>  change.  Famous last words I'm sure.

This is my exact reasoning to ask you to keep the driver system in place
and just modify it to allow Jangle as a possible driver.  Modify what
you expect from our driver - that's fine.  But please don't expect that
adding yet one application to this stack will make things easier for
everyone - or even most of us.

>> 8. The ILS-DI: I won't go there. :-)
>
> Yeah - well Jangle will speak ILS-DI as one method of communication -
>  however I doubt anyone will ever end up using this.  My guess is 90%
>  of ILS interaction will go through ILS Drivers.

I agree that no one will end up using the ILS-DI method.  No ILS is
going to end up supporting that.  They'll say they do (like they did
with ERMI), but none of them will.  And with Ex Libris investing heavily
in Primo, I wonder if they'll have any real interest in making this a
reality for Voyager in North America or Aleph internationally.
SirsiDynix may support this in some ways, but only within their own user
communities.  They'll never release it to Jangle.

>> We probably can't resolve all this on the list, but if you can add
>>  any ideas or concerns, that would help Ross and me a lot in our
>> explanations.
>>

> Well as far as I can tell - everything seems to be positive from my
> angle.  The only negatives I see are implementing Jangle in Ruby -
> when the VuFind community has been developing its ILS Drivers in PHP.
>  Other than that, it seems like a great solution to me.

I still want to hear very, very specific reason why this is so positive.
  There is just so much unknown, and it is all moving so fast, that I
just don't see how you are so comfortable with it when you aren't even
sure you can support the language (Ruby) within VuFind.

Tim

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Vufind-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vufind-tech
Reply | Threaded
Open this post in threaded view
|

Re: Jangle: Why such an emphasis?

Ross Singer-2
In reply to this post by James Farrugia
I've been following this thread with some interest.  VuFind is, in my
mind, one of the major use cases of Jangle (along with other OPAC
replacements, courseware, federated search and other things), so its
needs are one I think definitely should be met.

Before diving into the play-by-play replies, I want to make it clear
(because this has been a _major_ source of confusion, obviously):
Jangle is not Ruby.  Jangle is AtomPub and only AtomPub.  The
reference implementation is in Ruby, but that's only because I'm a
Ruby developer and the proof-of-concept needed to be built quickly
(and I can't write in anything as quickly as Ruby).  Ideally, the
Jangle "core" would eventually be deferred to an Apache Abdera adapter
or the like.  There's php-atompub-server, too.  Last week I started
breaking ground on a PHP connector framework for Jangle using the
Konstrukt framework.  Since the connector architecture just has to
return JSON over HTTP (preferably RESTfully, although Jim and I
working around that, currently, with mod_rewrite), the connectors can
be written in _anything_.  Bring forth your Erlang, your .NET, your
FORTRAN.

And now onto inline comments...

On Mon, Jul 7, 2008 at 12:18 PM, James Farrugia <[hidden email]> wrote:

> As things stand now, there's this Unicorn.php driver in VuFind that talks to a back-end Unicorn server script to return item info for the getHolding and getHoldings functions. These two pieces (driver and Unicorn server script) are what we've put our time into and what we plan on continuing to develop with, say, functionality for MARC Holdings and user account stuff, at least.
> So far, SirsiDynix is ok with what we're doing with "read-only" API stuff on the Unicorn server, and they've given us
> permission to share that code within the broader Unicorn/VuFind group. Once we get to user account info, though, that'll
> involve "read-write" APIs on the Unicorn end, and I don't think we've yet worked out with Sirsi how to share this code with the Unicorn/Vufind group.
>

I'll be honest that I don't really "get" what the problem is about
whether you're sharing a connector for VuFind or Jangle.  As long as
the sharing is restricted to the SD API community, what, functionally,
is the difference?  One of the reasons that Jangle is, intentionally,
detached from core and connector is so the connector can be closed
source or be intercepted by a middle layer that augments a closed,
semi-functional connector.

> When Andrew mentions that he sees it as a clear decision to utilize Jangle as the ILS Layer for VuFind
> just as we use Solr for the searching layer, it makes me nervous, for a couple of reasons.
>
> One, I still don't get Jangle, and even supposing it's the perfect way forward for VuFind, I as a Unicorn/VuFind person have a lot of concerns that haven't yet been addressed. Tim mentioned some, and let me echo some of them and add a few perhaps.
>
> 1. The Unicorn/VuFind people have invested a lot of time in doing things a la Unicorn.php and vufind.pl (the driver and corresponding backend Unicorn server script), and to learn that there will be a new way of abstracting drivers into Jangle
> just makes me nervous, since it seems like yet more overhead to learn and it will amount to switching horses in midstream.
>

Although, on the flip side, with all of the effort that is going to
making a Unicorn driver for VuFind, it seems to me that it would much
more useful if, rather than being VuFind specific, could be used in
any variety of client consumers, such as CMSes and courseware.

> 2. Jangle may be a great way to do what it proposes to do, but most of us I think are still in the dark about what it proposes
> to do and why it may indeed be great. What's it all about and why is it wonderful?  More to the point, why is it the right
> way for VuFind to go with its drivers? What functionality will be gained? What will be lost?  Also, VuFind is much more
> developed than Jangle is right now, and it's hard to consider moving to a platform that is less developed.

There's a lot in this point and I'm not sure I can answer a lot of it.
 What *I* like about Jangle is that it's taking a very simple approach
to exposing library content using a protocol that has a lot of client
and application support.  It's also creating permanent, reusable,
dereferenceable URIs for all manners of library resources (from
patrons to bib records to holdings and more) which can then be used in
other applications to unambiguously refer to one another.

Why I think it's a good idea for VuFind (I don't think there has to a
"right" way) is that it automatically broadens your potential
developer base beyond those that are directly interested in using
VuFind.  Regardless of how popular VuFind may get, it will always be a
percentage of the OPAC replacement market which is a percentage of all
the potential consumers of library data.

>
> 3. Jangle uses the Atom Publishing Protocol. Why?  Won't that severely limit the bibliographic metadata from a MARC bib record, for instance?

Not in the slightest.  Atom Syndication format has the atom:content
field which can include any other kind of record or file in it.
Jangle's Resource entity currently returns results as MARC21, MARCXML
and OAI_DC.  The Actor entity returns vCard and, if it was necessary,
could return FOAF.  The Item entity returns a representation of the
DLF ExpandedRecords simpleAvailability and ISO 20775 holdings wouldn't
be a problem (although it's not clear whether this is more appropriate
for a front-end adapter, since it conflates the separation of entities
a bit).  MFHD could be returned if it's available locally (and I'll
look at it when I start building the Alto adapter).

As to why:  AtomPub is a well-defined, widely used REST protocol.
Rather than creating yet another library-specific solution to a
generic problem, why not use something that is well-documented and has
a large client base?

>
> 4. Jangle uses JSON (not XML), but our Unicorn.php and vufind.pl use XML, so there's more overhead (and, ..., Ruby? ) to learn if we go the Jangle route.

Well, Jangle connector-core intercommunication is done using JSON,
yes.  Jangle core to client apps (which is the 'public' interface)
exposes via Atom feeds, so, XML.

As I said before, there's no Ruby required.

As to the JSON serialization, I really don't think that this will be
very expensive, honestly.  If you find a serious performance drain,
XML based communication can be addressed, but I'd be quite surprised
if this was any real bottleneck.
>
> 5. What specific kind of changes would Unicorn/VuFind folks need to make to the Unicorn driver and back-end server script
> to create a Jangle connector, and how exactly would such a connector work with the Jangle core?
>
> 6. SirsiDynix is on board with the Unicorn/VuFind group doing things as we've been doing them. It's an open question whether they'd be on board if we migrated our drivers to Jangle.
>

See my above statement.  Functionally, it should make no difference.
If Dan Scott is able to distribute a perl script that _helps you
migrate off of Unicorn_
(http://www.coffeecode.net/archives/161-Get-out-of-jail,-go-free,-part-I.html),
I can't see how distributing a script that would make Unicorn/Symphony
more attractive would be frowned upon, honestly.

> 7. How does VuFind need to be re-architected to migrate VuFind drivers to Jangle? By when will that happen?
>
> 8. The ILS-DI: I won't go there. :-)
>

Jangle is intended to support ILS-DI.  One of the external adapters
(Jangle is effectively three tiers:  connectors communicate directly
with backend systems like ILSes; core which proxies the connectors and
serializes to Atom; and adapters which take the AtomPub and turn it
into other protocols such as OAI-PMH and NCIP) is an ILS-DI service,
currently offering Level 1 compliance (although more is possible).  My
argument here is that ILS-DI functionality won't happen overnight,
Jangle enables it to happen much more quickly (and instantaneously for
everybody).

Another way to look at it is Jangle is a lower level API than ILS-DI.

-Ross.

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Vufind-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vufind-tech
Reply | Threaded
Open this post in threaded view
|

Re: Jangle: Why such an emphasis?

Dan Scott
I've not really been following this thread, but do want to clarify one
thing (off-topic though it may be):

2008/7/7 Ross Singer <[hidden email]>:
>> 6. SirsiDynix is on board with the Unicorn/VuFind group doing things as we've been doing them. It's an open question whether they'd be on board if we migrated our drivers to Jangle.
>>
>
> See my above statement.  Functionally, it should make no difference.
> If Dan Scott is able to distribute a perl script that _helps you
> migrate off of Unicorn_
> (http://www.coffeecode.net/archives/161-Get-out-of-jail,-go-free,-part-I.html),
> I can't see how distributing a script that would make Unicorn/Symphony
> more attractive would be frowned upon, honestly.

Until SirsiDynix states publicly that scripts with the
Unicorn/Symphony API can be freely distributed, the
"get-out-of-jail-free" script is available only within the API
Repository. So "distribute" might imply something more than is
currently possible, given my low tolerance for legal risks. (Once
SirsiDynix _does_ allow scripts using their open API to be distributed
freely, then of course the terms of the GPL can be fulfilled and all
and sundry can redistribute the "get-out-of-jail-free" script).

That said, any script that uses the API can be shared within the
protective folds of the SirsiDynix API Repository, which is run by the
user group. So both a Jangle connector for Unicorn/Symphony and a
direct VUFind driver for Unicorn/Symphony would be able to live there.
I concur with Ross that it seems unlikely that SirsiDynix would try to
quash either script. (And, I just checked: script 228, "Export Unicorn
Data", is still there in all of its simplistic glory).

Ah well, I can't avoid sharing one more thought in passing: there's
more to the "alternate public interface for our ILS" universe than
just VUFind. As good as VUFind is, and it is good, there are other
projects striving to achieve similar goals. Going with a more generic
connector layer such as Jangle makes sense if you want to avoid tying
yourself to a single option, or for avoiding doing the same work (only
targeted towards a different set of front-end specific APIs, probably
in a different language) to tie your ILS to a different front end. I
personally think the VUFind-on-Jangle approach is a good strategy, but
then I don't have nearly as much skin in the game as the rest of the
people on the list.

--
Dan Scott
Laurentian University

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Vufind-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vufind-tech
Reply | Threaded
Open this post in threaded view
|

Re: Jangle: Why such an emphasis?

Ross Singer-2
In reply to this post by Tim McGeary
Ok, another response before I finished editing my reply...

On Mon, Jul 7, 2008 at 3:11 PM, Tim McGeary <[hidden email]> wrote:
>
> So are you saying that VUFind will support BOTH Jangle as an ILS
> interactive layer AND the ILS Drivers as they stand now?  If not, then
> what you saying is that VUFind will fork, correct?

I'm confused as to why this has to be a zero-sum game.  Why wouldn't
you have a Jangle driver that behaves in all intents and purposes like
the Unicorn driver?

In PHP terms, I look at it like using ADODB:  theoretically it
shouldn't matter if it's MySQL, PostreSQL or SQLite under the hood, as
long as they all have ADODB drivers.

>
> I don't see how this is different than what you have built into VUFind.
>  You are asking ILS drivers to communicate to VUFind is a specific way.
>  It's up to those in each ILS community to come up with a driver to
> communicate with VUFind in that specific way.
>
> Jangle is seeking the very same thing, except using Atom and Ruby.
>

Well, except that the output can then be used by Blacklight or Moodle
or Blackboard or Primo or LibraryFind as well as VuFind.  A
VuFind-native driver doesn't offer that.

And again, only Atom, no Ruby.

>
> Actually, Andrew, with all due respect, you only mentioned a few reasons
> at a high level mosty about how Jangle abstracts the ILS interaction to
> another component like SOLR.  Quite frankly, that isn't a good enough
> reason yet because Jangle, for all intents and purposes, is still
> vaporware.

I'm curious about this statement.  How is a working implementation
with the goal of bring two more on by the end of the month considered
"vaporware"?  Is it new, slightly volatile and actively in
development?  Yes, certainly.  It's also being developed
transparently, direction is voted upon by the community, there's a
fully working demo with an admittedly crude ILS and the code is
entirely open contribution or critique.

>
> What we are seeking are very specific details.  We are elbow-deep in our
> efforts to make VUFind usable for SirsiDynix Unicorn/Symphony users: a
> large (actually THE largest) available ILS community out there.  And
> more specifically, we want to stay at the same level with VUFind and not
> have to fork off because of this issue.
>

Again, I don't see how the threat of forking is relevant or terribly useful.

>
> Problem #1:  Jangle won't be able to have a series of ILS drivers
> loaded.  That would be in major violation of our ILS non-disclosure
> agreements.  It is foolish to think otherwise.  Part b of this is that
> we have already come to a written agreement with our ILS to release our
> VuFind ILS driver to our ILS community for a specific product.
>

Jangle wouldn't have _any_ ILS connectors loaded by default.  That's
why the connectors are completely different applications from the
core.  The vendors or communities can control the development, the
NDAs, the whatevers and as long as there's an HTTP port open somewhere
and the server responds to /actors/ /resources/ /items/ /collections/
and /services/ (well, really, just /services/), we're golden.

> Problem #2:  Again, this is no different than the process of building
> drivers for VuFind, except that we have already bought into VuFind as a
> solution for a DI, but we have no idea what realistic future Jangle has.
>

True.  But I would wager that if Jangle fails (and, certainly, there
are no guarantees -- there are no guarantees with VuFind or any other
project, for that matter) there will be some other push for a unified
ILS abstraction layer as discovery systems grow more commonplace and
people see what they're able to do once their data is open.

> Side note because you mention this later: If you, as the lead of VUFind,
> are saying to us that Jangle is going to be the only supported
> interactive ILS-DI layer, yet then throw in a possibility of havinv to
> fork Jangle into PHP in order to make that work, how do I go to my
> decision makers and confident say "VuFind the discovery interface we
> will move to next and it will work long term"???  I really can't,
> because neither you or I can't realistically answer that.

Again, if VuFind has an abstract driver API, this is a non-issue.  The
Jangle driver can co-exist peacefully with a Polaris driver.  Since I
doubt anybody is recommending implementing Jangle-specific
functionality willy-nilly throughout VuFind controllers and views,
however the Jangle driver works can certainly be replicated in a
native driver.

>
> So why add this level of ambiguity to an otherwise remarkable development?
>
>
>> 4.) "by moving our ILS Drivers into the Jangle community, that allows
>>  other users of other DI systems to contribute to the source code,
>> only growing the community of developers even larger."
>
> See Problem #1 above.  If this is going to be successful, Jangle will
> have to fork N times where N is the # of proprietary ILS products that
> will allow their user community to share drivers amongst each other.

Jangle would require no forking.  Jangle is a spec, not an
application.  Since the connectors are free-standing and completely
independent of each other, N can be infinite, honestly.

>
>> 5.) "Jangle gives us a platform to standardize this communication.
>> The Unicorn guys are building this great client/server style app ...
>> but what about all of the other ILS systems that need similar
>> communication.  If we have a standardized communication layer, it
>> would make future development a lot easier."
>
> What expectation is out that that other ILS systems communicate in the
> same way?  From having experience with 2 of the 4 major proprietary
> systems, I can venture a safe guess that none of them have anywhere
> close to communicate methods similar with exception of maybe dumping out
> their bibliographic records.  SirsiDynix's API is unlike any other system.

Yes and no.  The Unicorn API *is* unique, certainly, but there are
other ILSes that provide at least as much read-only capability.
Voyager gives you complete read access to the RDBMS.  Horizon gives
you read-write!  Aleph gives you the X-Server.

III... well... let's not go there.
>

>>
>> I would hope nothing.  If we adopt jangle in ruby, then I would
>> assume we would need to port to ruby - unless ruby can understand
>> php. But then again, I b ring up the idea of PHangle - and then
>> nothing would need to be done.
>
> This is exactly my fear.  This quite possible requires a complete
> re-write of the drivers.  What if this is a deal breaker to those who
> are using VUFind within the existing driver system and aren't able to
> support Ruby?  Can we expect them to just hope PHangle will become
> reality instead?  I can't.
>

If it was written in Java, would that be better?  Do you care what
language Amazon's WS is written in?

>>> 6. SirsiDynix is on board with the Unicorn/VuFind group doing
>>> things as we've been doing them. It's an open question whether
>>> they'd be on board if we migrated our drivers to Jangle.
>>
>> The drivers would be the same - it's just whether Jangle reads the
>> response from the driver or vufind reads the response.
>
> No - you just said up above that the drivers wouldn't be the same, but
> that they'd have to be ported to Ruby or possibly PHangle.

Seriously.  They can be Perl.  Or Smalltalk.  Or Python.  It just
needs to spit out JSON.
>
>
> I agree that no one will end up using the ILS-DI method.  No ILS is
> going to end up supporting that.  They'll say they do (like they did
> with ERMI), but none of them will.  And with Ex Libris investing heavily
> in Primo, I wonder if they'll have any real interest in making this a
> reality for Voyager in North America or Aleph internationally.
> SirsiDynix may support this in some ways, but only within their own user
> communities.  They'll never release it to Jangle.

Maybe I'm being naive because I am paid by a vendor that intends to
support the Berkeley Accord (and I honestly believe Ex Libris will,
too -- if SD doesn't do it, somebody with API access will undoubtedly
do it for them).

The market is too small to only sell products to your installed base.
If I, as III or Ex Libris (or, let's go out on a limb and say I work
for a British library vendor with no marketshare in the US) could sell
my OPAC replacement system to SD, Polaris or Pica customers, why
wouldn't I try to make that possible?  Yes, it could mean that I lose
some of my ILS base if my product is inferior, but the number of
customers who _don't_ have my ILS greatly outnumbers those that do
(yes, even SD) so my profits potentially grow, anyway.  If it's an
inferior product, my ILS base is going to look elsewhere, anyway.

-Ross.

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Vufind-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vufind-tech
Reply | Threaded
Open this post in threaded view
|

Re: Jangle: Why such an emphasis?

Tim McGeary
Let me preface this reply by saying that Andrew and I had a long,
detailed conversation and I feel much better about the general idea of
using Jangle as a way of abstracting this process.

But that said, there are still a number of issues that I don't think are
being thought through properly or understood clearly.  So I'm going to
snip through Ross's last reply and add Dan's comments that tie in.

And, of course, I'll ask more questions...  I'll start with questions
and replies from Ross's email and then discuss the other topics at the
end.  Actually I'm going to copy/paste the sections up top here instead
snipping below.  I want to leave the context for others to catch up if
necessary.  Ok, here goes...

Ross Singer wrote:
> Jangle wouldn't have _any_ ILS connectors loaded by default.  That's
> why the connectors are completely different applications from the
> core.  The vendors or communities can control the development, the
> NDAs, the whatevers and as long as there's an HTTP port open somewhere
> and the server responds to /actors/ /resources/ /items/ /collections/
> and /services/ (well, really, just /services/), we're golden.

I think this makes more sense to me now, but I think, generally, there
is a lack of understanding of how difficult this may be for the average
library, or even the vendors, to produce.  This is similar to ERMI,
which is why my skeptical level is high.

For example, I know of one member library of our VUFind-Unicorn team
that does not have bi-directional HTTP traffic open to her ILS server.
 From my understanding of that situation, it may take an act of God to
change that security policy on their campus.

In my specific situation, I had to change Apache to run suEXEC to run
API commands through HTTP, which I've been told by more than a handful
of people that they'd be unwilling or unable to do on their Unicorn
server.

In general, Unicorn is very unReSTful, but there is hope because SD's
CTO is very much a fan of ReST.  That is why we are glad he is involved
in helping us work on our VuFind driver.

Tim McGeary wrote:
>> What expectation is out that that other ILS systems communicate in the
>> > same way?  From having experience with 2 of the 4 major proprietary
>> > systems, I can venture a safe guess that none of them have anywhere
>> > close to communicate methods similar with exception of maybe dumping out
>> > their bibliographic records.  SirsiDynix's API is unlike any other system.

Ross Singer wrote:
> Yes and no.  The Unicorn API *is* unique, certainly, but there are
> other ILSes that provide at least as much read-only capability.
> Voyager gives you complete read access to the RDBMS.  Horizon gives
> you read-write!  Aleph gives you the X-Server.
>
> III... well... let's not go there.

I learned more of that from Andrew, too, about Voyager and Aleph.
<sidenote> nice to hear that Ex Libris is going to make Voyager the
flagship ILS for North America.  I bet those Voyager sites out there are
relieved...</sidenote>

You can slowly forget about Horizon.  That is going to be EOL'd very
soon.  SirsiDynix is only going to support Symphony, which is Unicorn
with some Horizon features.

Ok, now the big issues.

Dan Scott wrote:
> Until SirsiDynix states publicly that scripts with the
> Unicorn/Symphony API can be freely distributed, the
> "get-out-of-jail-free" script is available only within the API
> Repository. So "distribute" might imply something more than is
> currently possible, given my low tolerance for legal risks. (Once
> SirsiDynix _does_ allow scripts using their open API to be distributed
> freely, then of course the terms of the GPL can be fulfilled and all
> and sundry can redistribute the "get-out-of-jail-free" script).

I'm glad that Dan commented on this, because I was going to correct Ross
on his statement that Dan was distributing his script.  Thanks, Dan.

The members of the VUFind-Unicorn team, through communication between me
and SD CTO Talin Bingham, negotiated the right to distribute the
VUFind-Unicorn driver to any SirsiDynix Symphony library regardless of
their API credentials.  This is HUGE!  For the first time ever, we don't
have to only place this in the SirsiDynix API repository.  Now the
catch...

Catch #1: the agreement states that we can distribute applications,
programs, and scripts ONLY to SirsiDynix users for uses within VUFind.
There are two pieces of this.  Technically, publishing the current
Unicorn.php code as using the GPL license is not adhering to this
agreement.  This will need to be changed.  And two, we shouldn't be
putting it into the VUFind trunk.

Catch #2: the current API-risk clause also still applies, meaning that
SD is not liable for a library running API scripts that go awry (it also
means that the using library would have to pay consulting fees for
recovery - not cheap).  Also now we (as developers) have to draw up
legal language to disclose possible harm or damage that could be done by
using this development and that is falls under the API-risk clause (see
above).  That hasn't been done yet either.

So in summary - the current code out there really isn't GPL and it is
missing required legal clauses.

Just importantly, as Andrew pointed out to me today, anyone can download
the VUFind code, including programmers from other apps like LibraryFind,
Blacklight, etc, and use our Unicorn.php driver.  That, too, is not
adhering to this agreement.

Even though the driver is currently only parsing XML output, it is still
nonetheless parsing output that came directly from SirsiDynix API.  A
workaround may be to modify the output on the other half of the driver,
which resides on the Unicorn/Symphony server so that it is more generic.
  Maybe this is where Jangle comes in better and can assist.

Now, it is entirely possible that we could get this agreement amended to
include a driver for Jangle, but at this time, we are limited to VUFind
from a distribution point of view.  In the meantime, I'll seek
clarification on what we have in place in the VUFind trunk, and begin
discussions with Talin about Jangle.

Ross Singer wrote:
> Maybe I'm being naive because I am paid by a vendor that intends to
> support the Berkeley Accord (and I honestly believe Ex Libris will,
> too -- if SD doesn't do it, somebody with API access will undoubtedly
> do it for them).

Just like we are dealing with and Dan indicated, somebody with API
access could not do this for them.  I wouldn't call you naive, but I
would encourage you to hold your breath either.  ;)

Personally, I don't understand the high importance put on the Berkeley
Accord.  It doesn't really mean jack.  First off, I think the vote by
the vendors was misrepresented by the DLF.  It wasn't an agreement to
implement whatever API specs the task force produce, but instead an
supportive endorsement that they should continue to pursue a spec and
they (vendors) would be open to examining it and *possibly* implementing
it in the future.  Betsy Graham of III put it best in her response to
the indicting comments people were making of III's abstention.
<Paraphrasing>You can't agree to do something that isn't yet
written</paraphrasing> and for III add <paraphrasing>especially when you
don't give out an API to your own customer</paraphrasing>.

My (and includes some others on this list) conversation with two
SirsiDynix executives this month show true skepticism that a common
protocol would be possible between the vendors in a ILS-DI API.  There
was a specific indication that the task force, and community in general,
does not understand the complexities of the circulation protocols that
are needed to communicate between current systems, and especially the
wide array of implementations (or not) of those protocols and standards
amongst customers.  When it is hard enough to get a single customer base
on the same standard, what would lead one to believe it could happen for
4-6 customer bases?  Quite frankly, that's an excellent point.  Just ask
anyone responsible for running an ILL consortia network.

That said, it is not unreasonable that each vendor will put out their
own version of "adoption" of the ILS-DI.  But the reality test we need
to keep doing is what percentage of libraries will be able to implement
that?  It reminds me just how cutting edge this all is, which is a good
and bad thing.  It's good because it presses us forward in ways that we
need to adapt.  It's can be a hindrance because on a priority scale
against the other projects that have implications on the literal
tomorrow (rather than the tomorrow of next year), the literal tomorrow
wins almost every time and this gets pushed back further and further.
In my case, that gap is closing fast where our OPAC's future has a
specific end date.

> The market is too small to only sell products to your installed base.
> If I, as III or Ex Libris (or, let's go out on a limb and say I work
> for a British library vendor with no marketshare in the US) could sell
> my OPAC replacement system to SD, Polaris or Pica customers, why
> wouldn't I try to make that possible?  Yes, it could mean that I lose
> some of my ILS base if my product is inferior, but the number of
> customers who _don't_ have my ILS greatly outnumbers those that do
> (yes, even SD) so my profits potentially grow, anyway.  If it's an
> inferior product, my ILS base is going to look elsewhere, anyway.

The market might be small, but you aren't talking about small $$$.  We
have to be honest: the cost of changing ILS's is impossible for a large
% of libraries.  They just don't have 6-figure $ laying around to spend
on a migration - and that includes to an OS ILS for two reasons: 1.)
they aren't mature yet and 2.) most libraries would still need
consulting power to make that move, whether it is LibLime or an
individual or two.

SirsiDynix's perspective, or at least the CTO's, is that they can't keep
up with the applications out there.  But they can keep up with the ILS.
  So if they make the ILS so strong and open that you can put whatever
applications you want on top, why would you leave?  I think that's wise.
  And I say that with a little irony as I'm about to start participating
in a multi-national OS library system architecture design project.

SD is releasing an ILS-DI this summer, too, that is so similar to VUFind
it is eerie.  They've already said they expect it would work for other
customers, but they aren't going to bother yet.  They want it to be
strong for their customer base.  For them, that's important, because as
the largest ILS vendor in the world, they have been lacking in
development focus with the past mergers they've done.  But they also
know how impossible it would be for 99% of the libraries to try such a
venture of putting a competitor ILS-DI on their ILS.

So instead, they want to push API certification, showing customers that
they can go use OS products with their ILS, which brings them continual
annual maintenance income, API-certification income, and they can focus
on their base product to be the best out there.  The fact is that the
products outside of the ILS isn't what is bringing in profitability.  It
is the ILS.  And with the bust of the ERM products, I see a general
hesitation in libraries to go with a competitor for a major component.
It remains to be seen how good Primo will do and be.

But that brings me to one last point.  The biggest academic libraries
that have the best ability to support open source are starting to sign
on with Primo:  BYU, Vanderbilt, Emory, Notre Dame.  Why is that?  Why
aren't they willing, like we are doing now, to put forth effort in the
open source ILS-DI arena?  That isn't an indictment at all, but a
question worth exploring.

In contrast, I'm the only one here at Lehigh working on this.  I
literally have 17 other projects.  Those four libraries in particular
have many more people available.  Yet so far, I've been able to
facilitate/co-lead a small team that got the CTO and VP of Product
Management of SD on campus for a meeting to discuss how THEY could help
US with VUFind.  I just find that an interesting twist to what has
general happened in the past in getting the attention of a vendor.

Ok, I think that's it - as if it weren't enough.  Sorry for the thesis,
but I hope that it shows my passion rather than anything negative.

Tim

Tim McGeary
Senior Systems Specialist
Lehigh University
610-758-4998
[hidden email]
Google Talk: timmcgeary
Yahoo IM: timmcgeary


> Ok, another response before I finished editing my reply...
>
> On Mon, Jul 7, 2008 at 3:11 PM, Tim McGeary <[hidden email]> wrote:
>> So are you saying that VUFind will support BOTH Jangle as an ILS
>> interactive layer AND the ILS Drivers as they stand now?  If not, then
>> what you saying is that VUFind will fork, correct?
>
> I'm confused as to why this has to be a zero-sum game.  Why wouldn't
> you have a Jangle driver that behaves in all intents and purposes like
> the Unicorn driver?
>
> In PHP terms, I look at it like using ADODB:  theoretically it
> shouldn't matter if it's MySQL, PostreSQL or SQLite under the hood, as
> long as they all have ADODB drivers.
>
>> I don't see how this is different than what you have built into VUFind.
>>  You are asking ILS drivers to communicate to VUFind is a specific way.
>>  It's up to those in each ILS community to come up with a driver to
>> communicate with VUFind in that specific way.
>>
>> Jangle is seeking the very same thing, except using Atom and Ruby.
>>
>
> Well, except that the output can then be used by Blacklight or Moodle
> or Blackboard or Primo or LibraryFind as well as VuFind.  A
> VuFind-native driver doesn't offer that.
>
> And again, only Atom, no Ruby.
>
>> Actually, Andrew, with all due respect, you only mentioned a few reasons
>> at a high level mosty about how Jangle abstracts the ILS interaction to
>> another component like SOLR.  Quite frankly, that isn't a good enough
>> reason yet because Jangle, for all intents and purposes, is still
>> vaporware.
>
> I'm curious about this statement.  How is a working implementation
> with the goal of bring two more on by the end of the month considered
> "vaporware"?  Is it new, slightly volatile and actively in
> development?  Yes, certainly.  It's also being developed
> transparently, direction is voted upon by the community, there's a
> fully working demo with an admittedly crude ILS and the code is
> entirely open contribution or critique.
>
>> What we are seeking are very specific details.  We are elbow-deep in our
>> efforts to make VUFind usable for SirsiDynix Unicorn/Symphony users: a
>> large (actually THE largest) available ILS community out there.  And
>> more specifically, we want to stay at the same level with VUFind and not
>> have to fork off because of this issue.
>>
>
> Again, I don't see how the threat of forking is relevant or terribly useful.
>
>> Problem #1:  Jangle won't be able to have a series of ILS drivers
>> loaded.  That would be in major violation of our ILS non-disclosure
>> agreements.  It is foolish to think otherwise.  Part b of this is that
>> we have already come to a written agreement with our ILS to release our
>> VuFind ILS driver to our ILS community for a specific product.
>>
>
> Jangle wouldn't have _any_ ILS connectors loaded by default.  That's
> why the connectors are completely different applications from the
> core.  The vendors or communities can control the development, the
> NDAs, the whatevers and as long as there's an HTTP port open somewhere
> and the server responds to /actors/ /resources/ /items/ /collections/
> and /services/ (well, really, just /services/), we're golden.
>
>> Problem #2:  Again, this is no different than the process of building
>> drivers for VuFind, except that we have already bought into VuFind as a
>> solution for a DI, but we have no idea what realistic future Jangle has.
>>
>
> True.  But I would wager that if Jangle fails (and, certainly, there
> are no guarantees -- there are no guarantees with VuFind or any other
> project, for that matter) there will be some other push for a unified
> ILS abstraction layer as discovery systems grow more commonplace and
> people see what they're able to do once their data is open.
>
>> Side note because you mention this later: If you, as the lead of VUFind,
>> are saying to us that Jangle is going to be the only supported
>> interactive ILS-DI layer, yet then throw in a possibility of havinv to
>> fork Jangle into PHP in order to make that work, how do I go to my
>> decision makers and confident say "VuFind the discovery interface we
>> will move to next and it will work long term"???  I really can't,
>> because neither you or I can't realistically answer that.
>
> Again, if VuFind has an abstract driver API, this is a non-issue.  The
> Jangle driver can co-exist peacefully with a Polaris driver.  Since I
> doubt anybody is recommending implementing Jangle-specific
> functionality willy-nilly throughout VuFind controllers and views,
> however the Jangle driver works can certainly be replicated in a
> native driver.
>> So why add this level of ambiguity to an otherwise remarkable development?
>>
>>
>>> 4.) "by moving our ILS Drivers into the Jangle community, that allows
>>>  other users of other DI systems to contribute to the source code,
>>> only growing the community of developers even larger."
>> See Problem #1 above.  If this is going to be successful, Jangle will
>> have to fork N times where N is the # of proprietary ILS products that
>> will allow their user community to share drivers amongst each other.
>
> Jangle would require no forking.  Jangle is a spec, not an
> application.  Since the connectors are free-standing and completely
> independent of each other, N can be infinite, honestly.
>>> 5.) "Jangle gives us a platform to standardize this communication.
>>> The Unicorn guys are building this great client/server style app ...
>>> but what about all of the other ILS systems that need similar
>>> communication.  If we have a standardized communication layer, it
>>> would make future development a lot easier."
>> What expectation is out that that other ILS systems communicate in the
>> same way?  From having experience with 2 of the 4 major proprietary
>> systems, I can venture a safe guess that none of them have anywhere
>> close to communicate methods similar with exception of maybe dumping out
>> their bibliographic records.  SirsiDynix's API is unlike any other system.
>
> Yes and no.  The Unicorn API *is* unique, certainly, but there are
> other ILSes that provide at least as much read-only capability.
> Voyager gives you complete read access to the RDBMS.  Horizon gives
> you read-write!  Aleph gives you the X-Server.
>
> III... well... let's not go there.
>
>>> I would hope nothing.  If we adopt jangle in ruby, then I would
>>> assume we would need to port to ruby - unless ruby can understand
>>> php. But then again, I b ring up the idea of PHangle - and then
>>> nothing would need to be done.
>> This is exactly my fear.  This quite possible requires a complete
>> re-write of the drivers.  What if this is a deal breaker to those who
>> are using VUFind within the existing driver system and aren't able to
>> support Ruby?  Can we expect them to just hope PHangle will become
>> reality instead?  I can't.
>>
>
> If it was written in Java, would that be better?  Do you care what
> language Amazon's WS is written in?
>
>>>> 6. SirsiDynix is on board with the Unicorn/VuFind group doing
>>>> things as we've been doing them. It's an open question whether
>>>> they'd be on board if we migrated our drivers to Jangle.
>>> The drivers would be the same - it's just whether Jangle reads the
>>> response from the driver or vufind reads the response.
>> No - you just said up above that the drivers wouldn't be the same, but
>> that they'd have to be ported to Ruby or possibly PHangle.
>
> Seriously.  They can be Perl.  Or Smalltalk.  Or Python.  It just
> needs to spit out JSON.
>>
>> I agree that no one will end up using the ILS-DI method.  No ILS is
>> going to end up supporting that.  They'll say they do (like they did
>> with ERMI), but none of them will.  And with Ex Libris investing heavily
>> in Primo, I wonder if they'll have any real interest in making this a
>> reality for Voyager in North America or Aleph internationally.
>> SirsiDynix may support this in some ways, but only within their own user
>> communities.  They'll never release it to Jangle.
>
> Maybe I'm being naive because I am paid by a vendor that intends to
> support the Berkeley Accord (and I honestly believe Ex Libris will,
> too -- if SD doesn't do it, somebody with API access will undoubtedly
> do it for them).
>
> The market is too small to only sell products to your installed base.
> If I, as III or Ex Libris (or, let's go out on a limb and say I work
> for a British library vendor with no marketshare in the US) could sell
> my OPAC replacement system to SD, Polaris or Pica customers, why
> wouldn't I try to make that possible?  Yes, it could mean that I lose
> some of my ILS base if my product is inferior, but the number of
> customers who _don't_ have my ILS greatly outnumbers those that do
> (yes, even SD) so my profits potentially grow, anyway.  If it's an
> inferior product, my ILS base is going to look elsewhere, anyway.
>
> -Ross.



-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Vufind-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vufind-tech
12