[jangle-discuss] Jangle Connector for SirsiDynix Symphony

[mg_ford]

Hello to everybody -- my first post in this group.

We have just won some funding to write a Jangle connector for
SirsiDynix's Symphony ILS/LMS, and are beginning to research possible
approaches. At present, the most likely looks like being to wrap perl
scripts around calls to the SirsiDynix transaction server. I'm still
getting my head around the relevant bits of the Jangle spec, and any
and all advice will be greatly appreciated.

There will be a project blog once we get going, and we'll be tweeting
(and posting elsewhere) under the #janglefb tag.

Cheers!

--
You received this message because you are subscribed to the Google Groups "jangle-discuss" group.
To post to this group, send email to jangle-...@googlegroups.com.
To unsubscribe from this group, send email to jangle-discus...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/jangle-discuss?hl=en.

[Andrew Nagy]

Hi!  There is a Unicorn/Symphony "connector" in the VuFind code base.  You might want to have a look at that.  Half of the code (the code with the API calls) is available from a private SD website.  I would imagine that you know what I am talking about, since I don't :)

http://code.google.com/p/vufind-unicorn/

There is also a VuFind-SirsiDynix listserv to discuss issues around the driver:
http://vufind.org/support.php

Good luck!
Andrew

[Ross Singer]

Hi! This is great news. Lord knows *anything* would be an
improvement on Unicorn/Symphony's current APIs.

My first bit of advice would be to not worry about the spec as a whole
too much at first and instead focus on what you want to bring back as
the specific resources (and their relationships).

What I mean by this is that rather than worry about how to return a
paged set of all of the holdings (for example) or implementing search,
start with individual resources and just work up from there.

Also, I would *definitely* recommend finding a good (and preferably
lightweight) REST framework to build on. I'm really out of touch with
Perl these days, but Mojolicious (http://mojolicious.org/) or Dancer
(http://perldancer.org/) seem right up Jangle's alley.

One of the nice things about Jangle is that you can always just return
a big XML document of everything you've got for a particular resource
and then later hack up an XSLT stylesheet to pass to the Jangle core
to transform it into something standard.

Good luck and I look forward to following the progress!
-Ross.

On Tue, Apr 27, 2010 at 9:31 AM, mg_ford <m.f...@leedsmet.ac.uk> wrote:

[Ford, Mike]

> -----Original Message-----

> From: jangle-...@googlegroups.com [mailto:jangle-

> dis...@googlegroups.com] On Behalf Of Andrew Nagy

> Sent: 27 April 2010 19:48

>

> Hi!  There is a Unicorn/Symphony "connector" in the VuFind code

> base.  You might want to have a look at that.  Half of the code (the

> code with the API calls) is available from a private SD website.  I

> would imagine that you know what I am talking about, since I don't

> :)

Thanks for the pointer -- I didn't know about this before. I'm surprised SD didn't mention it to us, as we were talking to them about the project even before the funding bid went in. Probably it's something the UK company doesn't know about.

Cheers!

Mike

 --
Mike Ford,
Electronic Information Developer, Libraries and Learning Innovation, 
Leeds Metropolitan University, C507, Civic Quarter Campus,
Woodhouse Lane, LEEDS,  LS1 3HE,  United Kingdom
Email: m.f...@leedsmet.ac.uk
Tel: +44 113 812 4730

To view the terms under which this email is distributed, please go to http://disclaimer.leedsmet.ac.uk/email.htm

[Ford, Mike]

> -----Original Message-----
> From: jangle-...@googlegroups.com [mailto:jangle-

> dis...@googlegroups.com] On Behalf Of Ross Singer
>
> Hi! This is great news. Lord knows *anything* would be an
> improvement on Unicorn/Symphony's current APIs.

Amen to that!

> My first bit of advice would be to not worry about the spec as a
> whole
> too much at first and instead focus on what you want to bring back
> as
> the specific resources (and their relationships).

Yes, that's pretty much what I'd been planning, as there's a second string to the project that involves building a Facebook app that uses Jangle to obtain a user's basic library account information -- # loans, # overdues, current fines/bills, maybe actual loan details later -- so returning some basic building blocks as first step suits us very well.

> Also, I would *definitely* recommend finding a good (and preferably
> lightweight) REST framework to build on. I'm really out of touch
> with
> Perl these days, but Mojolicious (http://mojolicious.org/) or Dancer
> (http://perldancer.org/) seem right up Jangle's alley.

Thanks -- one of us will take a look at those too. I'm not really clear at this stage what advantage such a framework brings, but useful to know that experts in the subject think they're worth it. Suspect my head is going to hurt a lot for a couple of weeks as I take it all in... ;)

Cheers!

Mike
--
Mike Ford,
Electronic Information Developer, Libraries and Learning Innovation,
Leeds Metropolitan University, C507, Civic Quarter Campus,
Woodhouse Lane, LEEDS,  LS1 3HE,  United Kingdom
Email: m.f...@leedsmet.ac.uk
Tel: +44 113 812 4730




To view the terms under which this email is distributed, please go to http://disclaimer.leedsmet.ac.uk/email.htm

[Emily Lynema]

How familiar are you with the Symphony APIs? I have the code (via Tim
McGeary, who played a major role in the Unicorn VuFind adapter) for a
'my account' type tool written using Sirsi API. It was created by
someone at Midlands Tech. I've looked at it briefly, and it looks to
be making web services out of Sirsi API commands via perl CGI scripts,
as many of us have done.

Let me know if you would like me to share that package with you
separately. I probably shouldn't share it with the list since it
involves the proprietary API commands.

In addition, here at NCSU we've written scripts to do the DLF
'getavailability' and also to place holds. I'm sure we'd be willing to
share, although I don't know how helpful it would be if you are
already familiar with the API.

One thing to think about that came up recently at my institution is
security. Even if you're not talking about transmitting user
information, you'll want to do some careful input checking at the
least. Someone could write a command line injection into that script
just like they can do SQL injections, since the input usually gets
piped to the command line at the start of any Sirsi API. And for user
information, encrypting or https is surely in order.

It's not that hard to create scripts that wrap Sirsi API commands to
do specific functions. It'll be more work to wrap the brain around
Jangle's resource-oriented view of things. Although what I think is
most difficult is to translate the things I'd want to do using Jangle
(like placing a hold or paying a fine) with Jangle's model. Seems like
I can only 'delete' a fine using Jangle if 'fine' is top-level
resource.

-emily lynema
NCSU Libraries

> > jangle-discus...@googlegroups.com<jangle-discuss%2Bunsu...@googlegroups.com>
> > .

> > For more options, visit this group at
> >http://groups.google.com/group/jangle-discuss?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups "jangle-discuss" group.
> To post to this group, send email to jangle-...@googlegroups.com.
> To unsubscribe from this group, send email to jangle-discus...@googlegroups.com.

> For more options, visit this group athttp://groups.google.com/group/jangle-discuss?hl=en.

[Ross Singer]

On Wed, Apr 28, 2010 at 2:56 PM, Emily Lynema <emily...@gmail.com> wrote:

> It's not that hard to create scripts that wrap Sirsi API commands to
> do specific functions. It'll be more work to wrap the brain around
> Jangle's resource-oriented view of things. Although what I think is
> most difficult is to translate the things I'd want to do using Jangle
> (like placing a hold or paying a fine) with Jangle's model. Seems like
> I can only 'delete' a fine using Jangle if 'fine' is top-level
> resource.

I don't disagree that it's often easier to think of these sorts of
things in a service (that is, "verb")-based context although I'm not
sure the end-result is any more or less complicated (and, certainly,
if "fines" were a resource, this would be trivial).

My approach to this in how Jangle is currently designed (where you
have actors, resources, items and collections exclusively -- obviously
this could be expanded if the need presents itself) would be to assume
that a "fine" is an attribute at the intersection of an actor and an
item. So let's say you have a overdue book at:

/jangle/actors/1234/items/5678

In the context actor 1234, there is a fine of $3 associated with item 5678.

Instead of deleting the fine, it's more likely you'd update (PUT) that
attribute.

Like I said, this isn't any simpler or necessarily "better", it's just
how I see it working in Jangle.

-Ross.

[Emily Lynema]

Ross,

I had not been thinking in terms of using PUT, GET, DELETE, etc. on attributes of resources. I like that idea.

-emily

[Ford, Mike]

> -----Original Message-----
> From: jangle-...@googlegroups.com [mailto:jangle-

> dis...@googlegroups.com] On Behalf Of Emily Lynema
> Sent: 28 April 2010 19:56
>
> How familiar are you with the Symphony APIs? I have the code (via
> Tim
> McGeary, who played a major role in the Unicorn VuFind adapter) for
> a
> 'my account' type tool written using Sirsi API. It was created by
> someone at Midlands Tech. I've looked at it briefly, and it looks to
> be making web services out of Sirsi API commands via perl CGI
> scripts,
> as many of us have done.

Thanks -- at this point, I'll take any and all contributions to help get us kick-started ;), so yes please! We have at least 3 people on the team who are API trained (myself twice, 7 years apart), and we have written Bincustom perl utilities for customized searches, custom reports using Sirsi's perl framework, and some perl fragments for iLink page customization. My personal background is as a programmer of (mumble-mumble) years' experience who's migrated in to Library IT systems, so this kind of project ought to be right up my alley. There does seem to be quite a lot to get our collective heads around, so I expect we'll be putting appearances in here a fair bit.

> In addition, here at NCSU we've written scripts to do the DLF
> 'getavailability' and also to place holds. I'm sure we'd be willing
> to
> share, although I don't know how helpful it would be if you are
> already familiar with the API.

Yes -- these might be interesting just to see how somebody else has done it, but as you say I don't know that we'd actually learn much from it.

> One thing to think about that came up recently at my institution is
> security. Even if you're not talking about transmitting user
> information, you'll want to do some careful input checking at the
> least. Someone could write a command line injection into that script
> just like they can do SQL injections, since the input usually gets
> piped to the command line at the start of any Sirsi API. And for
> user
> information, encrypting or https is surely in order.

Yes, indeed, we certainly need to take this into account -- especially as it's something that Sirsi itself is not historically good at (Cough! User credentials in the clear on every catalogue page? cough!). As I have a pretty tight PHP-based authentication system controlling admin access to the database behind our library website, I think I've got a fairly good handle on this one... I hope!

Cheers!

Mike
--
Mike Ford,
Electronic Information Developer, Libraries and Learning Innovation,
Leeds Metropolitan University, C507, Civic Quarter Campus,
Woodhouse Lane, LEEDS,  LS1 3HE,  United Kingdom
Email: m.f...@leedsmet.ac.uk
Tel: +44 113 812 4730




To view the terms under which this email is distributed, please go to http://disclaimer.leedsmet.ac.uk/email.htm

[Tim McGeary]

Mike,

I'd be happy to send you the MyAccount package (off list) if you don't
already have it. It's written in PHP.

Also, we are starting to test the new LDAP authentication for user
accounts with Symphony 3.3.1 to prep for a (hopeful) summer move to
VuFind and a separate MyAccount app like the package I have from
Midlands Tech. (still trying to hire a FT programmer to push this even
faster...)

I also have an signed PDF agreement from Talin Bingham (CTO at
SirsiDynix) that permits the VuFind-Unicorn connector to be released to
anyone in the Symphony user based regardless of API training. *IF/when*
we can get this Jangle connector to work as the VuFind connector, I see
no reason why that agreement cannot be extended, which was my POV at a
dinner at code4lib2009 when Andrew Nagy, Bess Sadler, Ross Singer,
myself and other plotted about how Jangle, VuFind, and Blacklight could
work together in this area.

Cheers,
Tim

--
Tim McGeary
Team Leader, Library Technology
Lehigh University
610-758-4998
tim.m...@lehigh.edu

timmc...@gmail.com
GTalk/Yahoo/Skype: timmcgeary

[Ford, Mike]

> -----Original Message-----
> From: jangle-...@googlegroups.com [mailto:jangle-
> dis...@googlegroups.com] On Behalf Of Tim McGeary
> Sent: 04 May 2010 21:46
> To: jangle-...@googlegroups.com
> Subject: Re: [jangle-discuss] Re: Jangle Connector for SirsiDynix
> Symphony
>
> Mike,
>
> I'd be happy to send you the MyAccount package (off list) if you
> don't
> already have it. It's written in PHP.

Terrific. As I said before, I'll take any and all help to get us kick-started -- and our everyday scripting language is PHP, so no problems there.

> Also, we are starting to test the new LDAP authentication for user
> accounts with Symphony 3.3.1

Ooh, interesting -- we're planning to go to 3.3 in May (test) and June (live), and are very interested in the LDAP authentication. Would be interested to get any interesting news you care to share (off this list, of course -- maybe on the SD
Customer Care lists?).

> I also have an signed PDF agreement from Talin Bingham (CTO at
> SirsiDynix) that permits the VuFind-Unicorn connector to be released
> to
> anyone in the Symphony user based regardless of API training.
> *IF/when*
> we can get this Jangle connector to work as the VuFind connector, I
> see
> no reason why that agreement cannot be extended, which was my POV at
> a
> dinner at code4lib2009 when Andrew Nagy, Bess Sadler, Ross Singer,
> myself and other plotted about how Jangle, VuFind, and Blacklight
> could
> work together in this area.

One of the conditions of our funding is that anything we produce has to be open source -- so you can pick it up and run with it any way you want.

[Ford, Mike]

> -----Original Message-----
> From: jangle-...@googlegroups.com [mailto:jangle-
> dis...@googlegroups.com] On Behalf Of Ford, Mike
> Sent: 06 May 2010 09:22


> One of the conditions of our funding is that anything we produce has
> to be open source -- so you can pick it up and run with it any way
> you want.

Incidentally, on that topic: we are also mandated to place our source code in an open code repository (such as Google Code!) with technical documentation alongside it. I'm presuming that eventually the code will want to end up in the jangle repository, but is the preference for us just to commit there from the word go, or should we set up our own separate Google Code repository? (The latter has some advantage for us, as there is a second string to the project which is not properly part of Jangle itself.)

[Ross Singer]

On Thu, May 6, 2010 at 5:20 AM, Ford, Mike <M.F...@leedsmet.ac.uk> wrote:

> Incidentally, on that topic: we are also mandated to place our source code in an open code repository (such as Google Code!) with technical documentation alongside it. I'm presuming that eventually the code will want to end up in the jangle repository, but is the preference for us just to commit there from the word go, or should we set up our own separate Google Code repository? (The latter has some advantage for us, as there is a second string to the project which is not properly part of Jangle itself.)

I would go with the latter, which is also what I've done with the PHP
libraries: http://code.google.com/p/phpjangle/ and the Talis Alto
connector: http://code.google.com/p/talislms-jangle/. Links can be
provided to all these from the main the Jangle site and the code site,
so I don't think it's a problem to distribute them.

I think if PHP is an option, this will give you a significant
advantage -- taking the VuFind Symphony driver and schmushing it in a
Jangle connector (esp. since the connector library sets up all of your
responses and whatnot) would get you something to poke at pretty
quickly.

-Ross.

[Ford, Mike]

> -----Original Message-----
> From: jangle-...@googlegroups.com [mailto:jangle-

> dis...@googlegroups.com] On Behalf Of Ross Singer
> Sent: 06 May 2010 13:18
>
> On Thu, May 6, 2010 at 5:20 AM, Ford, Mike <M.F...@leedsmet.ac.uk>
> wrote:
>
> > Incidentally, on that topic: we are also mandated to place our
> source code in an open code repository (such as Google Code!) with
> technical documentation alongside it. I'm presuming that eventually
> the code will want to end up in the jangle repository, but is the
> preference for us just to commit there from the word go, or should
> we set up our own separate Google Code repository? (The latter has
> some advantage for us, as there is a second string to the project
> which is not properly part of Jangle itself.)
>
>
> I would go with the latter, which is also what I've done with the
> PHP
> libraries: http://code.google.com/p/phpjangle/ and the Talis Alto
> connector: http://code.google.com/p/talislms-jangle/. Links can be
> provided to all these from the main the Jangle site and the code
> site,
> so I don't think it's a problem to distribute them.

Thanks for that -- we'll go that route then.

> I think if PHP is an option, this will give you a significant
> advantage -- taking the VuFind Symphony driver and schmushing it in
> a
> Jangle connector (esp. since the connector library sets up all of
> your
> responses and whatnot) would get you something to poke at pretty
> quickly.

PHP is our everyday scripting language, so having examples in PHP is certainly helpful. The reasoning behind perl is that all SirsiDynix's utilities are written in it, so it's pretty much guaranteed to be available on any out-of-the-box Symphony ILS. Guess we'll just have to suck it and see.

Cheers!

Mike
--
Mike Ford,
Electronic Information Developer, Libraries and Learning Innovation,
Leeds Metropolitan University, C507, Civic Quarter Campus,
Woodhouse Lane, LEEDS,  LS1 3HE,  United Kingdom
Email: m.f...@leedsmet.ac.uk
Tel: +44 113 812 4730





To view the terms under which this email is distributed, please go to http://disclaimer.leedsmet.ac.uk/email.htm

[Tim McGeary]

Ford, Mike wrote:
>> Also, we are starting to test the new LDAP authentication for user
>> accounts with Symphony 3.3.1
>
> Ooh, interesting -- we're planning to go to 3.3 in May (test) and
> June (live), and are very interested in the LDAP authentication.
> Would be interested to get any interesting news you care to share
> (off this list, of course -- maybe on the SD Customer Care lists?).

My systems specialist, Mark Canney (mac...@lehigh.edu) is working on
this right now. He's the best person to contact off-list. Bucknell
University already has LDAP running in production. Bill Burkholder
(burk...@BUCKNELL.EDU) would be the best contact. Please tell him that
I referred you to him.

>> I also have an signed PDF agreement from Talin Bingham (CTO at
>> SirsiDynix) that permits the VuFind-Unicorn connector to be
>> released to anyone in the Symphony user based regardless of API
>> training. *IF/when* we can get this Jangle connector to work as the
>> VuFind connector, I see no reason why that agreement cannot be
>> extended, which was my POV at a dinner at code4lib2009 when Andrew
>> Nagy, Bess Sadler, Ross Singer, myself and other plotted about how
>> Jangle, VuFind, and Blacklight could work together in this area.
>
> One of the conditions of our funding is that anything we produce has
> to be open source -- so you can pick it up and run with it any way
> you want.

While I understand this condition of your funding, for full clarity and
disclosure, I want to advise you to NOT publish any proprietary
SirsiDynix API code as open source. While there are efforts to bring
SirsiDynix to a table to discuss opening their API to others, they have
not done so, and I would fully expect their (relatively) new ownership
(Vista Equities) to go after any violations of their software
agreements, which include not publishing API code.

As I'm sure you are aware, the SirsiDynix user community has an API
repository only available to other API users. My agreement extends
releasing VuFind connector code to all SirsiDynix users, but it does not
extend beyond the user base. I would advise you to separate the API
code from your original code in a separate file, and not to post that
API code in a Google code or SourceForge-type site. Either ask a
requestor to prove their SirsiDynix user status or post the code into
the API repository.

That all said, I'm very excited for your plans. Once I get a programmer
hired, I'd like them to get involved of what you have done so far so we
can do similar work here at Lehigh.

Cheers,
Tim

--
Tim McGeary
Team Leader, Library Technology
Lehigh University
610-758-4998
tim.m...@lehigh.edu

timmc...@gmail.com
GTalk/Yahoo/Skype: timmcgeary

[Ford, Mike]

> -----Original Message-----
> From: jangle-...@googlegroups.com [mailto:jangle-
> dis...@googlegroups.com] On Behalf Of Tim McGeary

> Sent: 06 May 2010 16:22


> While I understand this condition of your funding, for full clarity
> and
> disclosure, I want to advise you to NOT publish any proprietary
> SirsiDynix API code as open source. While there are efforts to
> bring
> SirsiDynix to a table to discuss opening their API to others, they
> have
> not done so, and I would fully expect their (relatively) new
> ownership
> (Vista Equities) to go after any violations of their software
> agreements, which include not publishing API code.

Ah, yes, thanks for that. I think that's an issue that in the excitement of winning funding and getting started we probably hadn't thought about. However, we do have SirsiDynix UK involved as consultants (even if only minimally) so hopefully they'd have offered us the same advice in the event ....!!

Cheers!

Mike
--
Mike Ford,
Electronic Information Developer, Libraries and Learning Innovation,
Leeds Metropolitan University, C507, Civic Quarter Campus,
Woodhouse Lane, LEEDS,  LS1 3HE,  United Kingdom
Email: m.f...@leedsmet.ac.uk
Tel: +44 113 812 4730





To view the terms under which this email is distributed, please go to http://disclaimer.leedsmet.ac.uk/email.htm

[Tim McGeary]

Ford, Mike wrote:
>> -----Original Message----- From: jangle-...@googlegroups.com
>> [mailto:jangle- dis...@googlegroups.com] On Behalf Of Tim McGeary
>> Sent: 06 May 2010 16:22
>
>
>> While I understand this condition of your funding, for full clarity
>> and disclosure, I want to advise you to NOT publish any
>> proprietary SirsiDynix API code as open source. While there are
>> efforts to bring SirsiDynix to a table to discuss opening their API
>> to others, they have not done so, and I would fully expect their
>> (relatively) new ownership (Vista Equities) to go after any
>> violations of their software agreements, which include not
>> publishing API code.
>
> Ah, yes, thanks for that. I think that's an issue that in the
> excitement of winning funding and getting started we probably hadn't
> thought about. However, we do have SirsiDynix UK involved as
> consultants (even if only minimally) so hopefully they'd have offered
> us the same advice in the event ....!!
>
> Cheers!

I'm glad that SirsiDynix UK consultants are involved. I would
absolutely expect them to advise you of this same thing along the way.
In either event, I'm very excited you are working on this. Keep us posted!

Tim