Community consensus on "next priority"
Ross Singer
With the 1.0 release starting to stabilize, it's time for us to begin
thinking about how to actually apply Jangle towards the most
beneficial use to promote adoption.
Obviously, direct development of Jangle-y things have been minimal
(read: mostly non-existent) outside of me and I attribute that mainly
to it being still mostly an academic project at this point, meaning,
"I can't download it and see it's value immediately in the project I'm
involved with". (The other possibility is that people legitimately
don't find the spec useful, but I would prefer that to be proven
first.)
So, this leaves the project in a bit of a chicken or egg position...
basically, which is the best way, with limited development
time/resources to "showcase" the potential?
Scenario #1)
Add Jangle functionality to a project like VuFind or Blacklight.
Advantage: Can show quickly, easily and effectively how Jangle
applies to the sorts of systems libraries are trying to deploy.
Disadvantage: Unless they use OpenBiblio or Talis Alto, they're going
to need a connector from somewhere. The percentage of Alto/OpenBiblio
customers interested in VuFind/Blacklight/Helios/etc. is minuscule (if
even existent) compared to the Unicorn, III, Voyager, Virtua and Aleph
customers who likely *do* fall into the realistic base of the NGCs.
Scenario #2)
Build connectors for Evergreen and/or Koha.
Advantage: More connectors mean more likely installed base.
Obviously the project choices here are pragmatic: an open (as in to
code against, not in source) and accessible Voyager, Symphony or
Millenium is not likely to fall into my lap. EG or Koha also boost
the credibility of Jangle from OpenBiblio a bit (although OpenBiblio
wasn't chosen for "credibility", of course).
Disadvantage: What are the immediate benefits of providing access to
the data in systems that are already open? What are the sorts of uses
that Koha/EG libraries would actually want from Jangle? The last
question is mainly because both of these projects provide what many
would consider a NextGen catalog already and that's probably the most
obvious application of Jangle at first (well, that and courseware --
but that's more of a local integration issue and also not an issue for
public libraries -- the primary implementer of both projects).
Scenario #3)
Build a connector library in PHP or Java to help developers build
their own apps.
Advantage: Well, it's not like I expect everybody to switch to Ruby.
Having classes available to easily serialize from the database or
whatever into the connector JSON responses (and possibly providing a
simple REST framework to plug into) would greatly lower the burden for
developers to actually make the needed connectors.
Disadvantage: I'm probably a pretty lousy candidate to actually do
this. A handful of cobbled together libraries in languages that I'm
less comfortable with seems like a sure-fire way to please nobody.
Also, while infrastructure is nice (and, eventually, necessary), I
don't generally buy into the "if you build it, they will come" ethos
when it comes to frameworks. Abstract ideas are not particularly good
ways to attract attention to a project.
Scenario #4)
Focus on building some more adapters like the DLF ILS-DI one and the UnAPI one.
Advantage: These are generally pretty simple and prove the point of
Jangle. An NCIP adapter, for example, would be good for both Jangle's
commitment to be a good library standards player but would also be
genuinely useful since the *lack* of consistent NCIP interfaces is
real impediment to interlibrary borrowing. Or, replace NCIP with
"useful adapter service people seem to want".
Disadvantage: Who in their right mind wants to deal with NCIP?
Seriously, though, it would be a half-measure until there's write
access via Jangle (although would be a good way to gather
requirements). Adapters, while a good way to show how Jangle can be
applied, are only useful if there are systems that have data that need
adapting.
So those are the four basic paths I see (with #1's targets able to be
swapped out with whatever: Biblios, ReservesDirect, SOPAC, SolrMARC,
Scriblio... I don't care). Anybody have any other possible proposals?
Obviously my time will be split with my other job functions (and, of
course, if somebody else sees one of these scenarios that would fancy
doing, I'd encourage that more than waiting for me), but this is a
priority me and for Talis, meaning it's something I can work on and it
doesn't have to directly benefit Talis if the outcome helps spread the
proliferation of Jangle in some meaningful way.
So what do people think?
Thanks,
-Ross.
Tim McGeary
Because I would could use another reason to get my act back into the
VuFind-Unicorn game (read: a reason to push away less interesting
things), I would be open to picking up where you and Jim Farrugia left
off in building the Unicorn connector.
There has been a significant growth in membership of the VuFind-Unicorn
listserv, and I committed to incorporating Stanford's effort in our
VuFind-Unicorn Perl connector to Jim's PHP connector. So I think there
is a possible community that can build momentum there.
I think it would be helpful to me and the Blacklight community if we
(VuFind-Unicorn and Blacklight folks) could do the Jangle-Unicorn
connector together, too, if that's possible. I still don't know enough
of the back-end similarities/differences that may help or hinder that
collaboration.
And a third piece to this response is that as a member of the Open
Library Environment (OLE) Project team, I'm also taken responsibility of
documenting the interoperability components/requirements for VuFind and
Blacklight for the OLE Project.
Tim
--
Tim McGeary
Senior Systems Specialist
Lehigh University
tim.m...@lehigh.edu
610-758-4998
timmc...@gmail.com
Google Talk: timmcgeary
Yahoo IM: timmcgeary
Steve Toub
most boost adoption:
1). Continued evangelism to open source discovery layer projects:
VuFind/Blacklight, SOPAC, etc. Sell, promote, cajole, press the flesh,
etc. for those projects to see the benefit of building connectors to
Jangle and have them do that development for you.
2). Connectors to closed source ILSes.
Continuing on with Unicorn/Symphony seems good but my understanding is
that API is pretty complete. Perhaps starting in on others in the most
need of liberation: Millenium? (Disadvantage: $10M lawsuits?) Might
try contacting Ex Libris or VTLS with the evangelism route, since they
seem most receptive to an open source/interoperability mindset.
3). Jangl-ification of an endpoint that ain't an ILS or discovery
layer: Biblios? Reserves Direct? eVanced? Amazon Listmania?
--SET
Steve Toub
Product Manager, BiblioCommons
Ross Singer
This would be a great contribution -- I mean, however much you have
time or the desire to do.
Steve's right, Unicorn's API *does* make it different from other
ILSes, but I would hardly call their API particularly developer
friendly or logical. But it's there, which makes a Jangle connector
pretty low hanging fruit (hopefully).
Jim made pretty good progress, I legitimately think it wouldn't take
much to get from what he wrote (which, of course, I haven't seen the
code or anything) to something that "works".
The JSON responses need to be tweaked a bit and paging needs to be
added. Outside that, it's totally at the discretion of the developer
to decide how best to implement the rest of it.
I also think it would be useful from an OLE perspective, honestly. My
takeaway from the webcast the other week was that Jangle and OLE are
trying to solve two very different problems, but they are not mutually
exclusive. Whatever OLE ultimately comes up with would be as eligible
for Jangle connectors as anything else. I'm not sure you can have too
many points of access to a service.
Can you get with Jim to see if he can give you the stuff he's already written?
-Ross.
Ross Singer
Yes, I definitely agree w/r/t evangelism on many fronts. We know the
vendors at least are aware of its existence (since they were all in
the room when I presented about it for the DLF), and I think that's a
start. But I think it's going to take customers actually requesting
it (on their support forums, mailing lists, etc.) for it take root.
After all, they all have similar API (well, not "all") type
initiatives in the works in some capacity.
More replies inline:
On Fri, Oct 17, 2008 at 3:27 AM, Steve Toub <steve...@gmail.com> wrote:
>
> My input from waaaay off in the peanut gallery on what I think would
> most boost adoption:
>
> 1). Continued evangelism to open source discovery layer projects:
> VuFind/Blacklight, SOPAC, etc. Sell, promote, cajole, press the flesh,
> etc. for those projects to see the benefit of building connectors to
> Jangle and have them do that development for you.
Right. This is the route I'm leaning towards. At the moment, I'm
playing around with hacking a proof-of-concept Jangle support into
fac-back-opac/Helios/Kobold Chieftain not because it's terribly
popular project, but because it's enough like VuFind/Blacklight to
make the point, but is much less formal and hackable which seems ideal
for a proof-of-concept. Like why OpenBiblio was chosen over Koha for
the first connector... make the point without the overhead.
>
> 2). Connectors to closed source ILSes.
> Continuing on with Unicorn/Symphony seems good but my understanding is
> that API is pretty complete. Perhaps starting in on others in the most
> need of liberation: Millenium? (Disadvantage: $10M lawsuits?) Might
> try contacting Ex Libris or VTLS with the evangelism route, since they
> seem most receptive to an open source/interoperability mindset.
>
Yeah, well, staying out of court would be nice :) Definitely E-L and
VTLS are the prime targets, although, again, don't their customers
have access to the RDBMS (and in the case of Aleph, X-Server)?
> 3). Jangl-ification of an endpoint that ain't an ILS or discovery
> layer: Biblios? Reserves Direct? eVanced? Amazon Listmania?
>
Well, this was my initial plan. Basically release an entire "library
suite" of connectors for OSS. A soup-to-nuts Janglified library:
ils, reserves, ill, etc. I'm interested to know how much people are
interested in this, because it'd be kind of a fun project.
-Ross.
Steve Toub
they're committed to an NCIP toolkit for the real-time stuff, but
since they're still initial development, may be an opportunity to sway
toward Jangle.
>> 2). Connectors to closed source ILSes.
>> Continuing on with Unicorn/Symphony seems good but my understanding is
>> that API is pretty complete. Perhaps starting in on others in the most
>> need of liberation: Millenium? (Disadvantage: $10M lawsuits?) Might
>> try contacting Ex Libris or VTLS with the evangelism route, since they
>> seem most receptive to an open source/interoperability mindset.
>>
> Yeah, well, staying out of court would be nice :)
On the other hand, it seems like Milennium has a quite a number of
connectors already (SOPAC, Scriblio, LibXess, Dave Walker's, a few
other non-SOPAC Drupal modules) and I haven't heard of any pushback
from III. Would be good to harmonize this community a bit.
--SET
Tim McGeary
Jim and I have already connected about his efforts since he is
transitioning to a new position. I should hopefully have all of his
code and documentation in about a week.
However much I can contribute is dependent on a number of things, but
given that 33% of my time is supposed to be spent on OLE-like things,
this can fit nicely there. VuFind and Blacklight are on my list of
responsibilities to investigate interoperability, and I will add Jangle
to that list in our group work space because it just makes sense.
Unicorn might have the most roburt API of the big ILS, but that doesn't
make it easier for this technology. The API isn't exactly friendly to
ReST, Web Services, or XML yet. In fact, I authored a collaborative
document about the bugs and failures of the xml output API commands to
SirsiDynix. I'm hoping those get resolved before the next release.
Time will tell...
Tim
Tim McGeary
Senior Systems Specialist
Lehigh University
610-758-4998
tim.m...@lehigh.edu
Walker, David
> other non-SOPAC Drupal modules) and I haven't
> heard of any pushback from III. Would be good
> to harmonize this community a bit.
A Jangle PHP port might be the catalyst that could bring these projects together, although I think John's SOPAC 2.0 may already be looking toward Jangle interoperability. Is he on this list?
--Dave
==================
David Walker
Library Web Services Manager
California State University
http://xerxes.calstate.edu
________________________________________
From: jangle-...@googlegroups.com [jangle-...@googlegroups.com] On Behalf Of Steve Toub [steve...@gmail.com]
Sent: Friday, October 17, 2008 8:46 AM
To: jangle-...@googlegroups.com
Subject: [jangle-discuss] Re: Community consensus on "next priority"
Bess Sadler
On Oct 16, 2008, at 4:00 PM, Tim McGeary wrote:
>
> I think it would be helpful to me and the Blacklight community if we
> (VuFind-Unicorn and Blacklight folks) could do the Jangle-Unicorn
> connector together, too, if that's possible. I still don't know
> enough
> of the back-end similarities/differences that may help or hinder that
> collaboration.
Tim, I think this is a fantastic idea and it's also what I'm hoping
for. Let's talk about how we can make this happen.
Bess
Ross Singer
> A Jangle PHP port might be the catalyst that could bring these projects together, although I think John's SOPAC 2.0 may already be looking toward Jangle interoperability. Is he on this list?
No, but he is registered on jangle.org and I did a Jangle presentation
for the Darien PL developer summit a couple of weeks ago, so, yeah,
he's aware of it. Of course, he's got his own Jangle-like piece in
SOPAC2 (although I'm not sure if it's LOCUM or InSURGE), so I'm not
sure how that affects things.
I agree that a PHP port is a very high priority (more than porting to
any other language, IMO), but what does that mean, exactly? Obviously
we're talking about the connector part here (the language a Jangle
core is written in shouldn't matter all that much), but what would a
PHP developer *want* in a connector framework? Does it just need to
serialize the proper JSON responses and plug into RESTful web
framework of choice? Or, like JangleR, provide the web framework,
serializations, etc... the only thing the developer needs to do is
plug in the appropriate objects for the various entities.
I don't really know the expectations among PHP developers when it
comes to stuff like this, and there seems to be almost zero consensus
among PHP frameworks (and way too many to choose from).
-Ross.
Andrew Nagy
On Fri, Oct 17, 2008 at 1:52 PM, Walker, David <dwa...@calstate.edu> wrote:
> A Jangle PHP port might be the catalyst that could bring these projects together
I agree that a PHP port is a very high priority (more than porting to
any other language, IMO), but what does that mean, exactly? Obviously
we're talking about the connector part here (the language a Jangle
core is written in shouldn't matter all that much), but what would a
PHP developer *want* in a connector framework? Does it just need to
serialize the proper JSON responses and plug into RESTful web
framework of choice? Or, like JangleR, provide the web framework,
serializations, etc... the only thing the developer needs to do is
plug in the appropriate objects for the various entities.
I'll throw my $.02 in here - since VuFind is developed in PHP - a PHP class that implements the jangle functionality would be excellent. I would advise that you don't implement any existing frameworks - since a library such as jangle needs to be lightweight and have no requirements. I like to model my php libraries after the requirements defined in the PEAR repository.
I would say for a PHP app - that you don't implement the REST component. One of the main reasons for a REST based API is that the API can be used in any language. So if you are talking about building a language specific implementation, then I don't feel that the REST part is necessary. With that said, I think Jangle should work just like any standard database abstraction layer. If you can model something like that - then you are golden.
Andrew
Walker, David
And, in that sense, I think Jangle -- or even the DLF ILS Discovery guidelines -- might just serve as a convenient motivator, or banner, under which we might consolidate our efforts. Good to tie these things into the wider community, and follow some conventions, rather than make them application specific.
I'm not sure that should discourage the development of a Jangle core in PHP, however. If I was a Perl or Java developer, and had the choice of a Ruby or PHP port of Jangle, I might go for the latter if my servers are already set-up for PHP, which I think is probably still more prevalent.
--Dave
==================
David Walker
Library Web Services Manager
California State University
http://xerxes.calstate.edu
Sent: Monday, October 20, 2008 12:58 PM
To: jangle-...@googlegroups.com
Subject: [jangle-discuss] Re: Community consensus on "next priority"
Ross Singer
>
> I think Andrew's right: Libraries developing PHP applications are unlikely to want to impose an additional HTTP call on top of fetching this data when your own PHP app could consume it directly.
Well, there are a lot of variables here -- I'm not sure one can assume
that everybody wants to run their Jangle core on the same machine as
their connector (only the web server may be available outside the
firewall, for example), but, yes, your point still stands. The way
this would work falls outside the scope of Jangle, though. Jangle
only defines HTTP connector/core communication (at this point), so how
this would work would be an exercise of the developer.
I'm also not entirely sure how much overhead an HTTP interface
imposes, but that's beside the point. If somebody wants to create a
consumable PHP library that's perfectly fine with me. I'd be
interested in seeing how it would/should work and would be happy to
write something similar in Ruby.
>
> And, in that sense, I think Jangle -- or even the DLF ILS Discovery guidelines -- might just serve as a convenient motivator, or banner, under which we might consolidate our efforts. Good to tie these things into the wider community, and follow some conventions, rather than make them application specific.
>
Well, the goal is nothing application specific. My point was, since
I'm not a PHP developer, I don't know what is good or useful for
someone who is a PHP developer.
> I'm not sure that should discourage the development of a Jangle core in PHP, however. If I was a Perl or Java developer, and had the choice of a Ruby or PHP port of Jangle, I might go for the latter if my servers are already set-up for PHP, which I think is probably still more prevalent.
>
We're just talking about priorities here. Porting the Jangle core to
PHP (or Java, for a different camp) seems unnecessary right now since
developers shouldn't need to hack on the Jangle core to begin building
apps based on Jangle. Obviously this will eventually change, since I
understand how local IT policy people may not want or allow Ruby
anywhere in their web stack, but worrying about that at this stage
seems counterproductive in the face of Jangle's multiple pressing
needs.
Now, again, if somebody else wanted to take this on, that would, of
course, be welcome.
-Ross.
Ross Singer
PEAR compliance or anything, but I should have something to poke at by
the end of the week.
-Ross.