Let's get this ball rolling

0 views
Skip to first unread message

Ross Singer

unread,
Apr 2, 2008, 12:47:38 PM4/2/08
to jangle-...@googlegroups.com
Hi everybody.

By now, the move of http://jangle.org/ to the neutral, 3rd party
webhost should have propagated across most DNS servers (although,
strangely this works from one of my computers, but not the other).
It's a Drupal site and while I figure we'll still use the Google Code
site, this is a good place for documentation, publicity and general
community building. If you want to volunteer to help admin the site,
drop me a line and I'll set you up.

I figure now that we've gotten the site up and the nonsense that is
April 1st out of the way, it's time to focus on getting our first
release of the spec underway. I realize all of you are incredibly
busy; if you can't contribute directly to defining the syntax of the
API, simple +1s or -1s will do as they'll at least help make sure this
project remains useful to you when we have something to work with.

I don't think we need to be dogmatic to the Rogue '05 "rules" -- we
should use them as guidelines (it would be nice to keep the spec short
and three implementations would be useful, but let's be realistic --
this is a much more sophisticated problem than COinS), but let's worry
more about the end product than the process.

Ok, so that being said, 30 days is short (;)) and I don't want to
start the "timer" until I'm sure we're making something that we
actually want. So +1 or -1 the following. Some of these are
contradictory, since I'm not trying to prescribe anything, but get a
feel for how you all want to proceed.

- The spec will be for exposing library services to the Atom
Publishing Protocol

- The first "use case" will be to support the DLF ILS & Discovery
Interface API (although not to the exclusion of other use cases)

- We should focus on GET (read) access across all of the resources
before worrying about C_UD

- We should get CRUD working on a single resource before we move on

- "Jangle" is effectively 2 parts, Jangle core (AtomPub interface)
and Jangle connectors that communicate via JSON and the semantics of
how library specific resources map to AtomPub semantics

- Start with 4 primitive resource types, "Actor", "Collection",
"Manifestation" (or "Metadata Record" or "Resource"), "Item"

I think tallying up votes for that can help us set the first 30 day cycle.

-Ross.

Andrew Nagy

unread,
Apr 2, 2008, 3:13:11 PM4/2/08
to jangle-...@googlegroups.com
Ross - everything that you list looks good and reasonable. Though I
am a bit too focused to give it all some good thought at the moment.

> - "Jangle" is effectively 2 parts, Jangle core (AtomPub interface)
> and Jangle connectors that communicate via JSON and the semantics of
> how library specific resources map to AtomPub semantics
>

I'd like to think a bit more about this and how it might be
structured. I don't want to over think this in the beginning - but I
would just like to throw out there a 3rd part. Just thinking from an
MVC pattern - the 3rd component would be the interface that would
allow us to easily change what interface module we want to use (OAI,
SRU, etc). Am I over thinking this?

Andrew

Galen Charlton

unread,
Apr 2, 2008, 3:26:35 PM4/2/08
to jangle-...@googlegroups.com
Hi,

On Wed, Apr 2, 2008 at 11:47 AM, Ross Singer <rossf...@gmail.com> wrote:

> I realize all of you are incredibly busy;

+2, alas, but I hope to have some time participate more actively soon.

> - The spec will be for exposing library services to the Atom
> Publishing Protocol

+1

> - The first "use case" will be to support the DLF ILS & Discovery
> Interface API (although not to the exclusion of other use cases)

+1

> - We should focus on GET (read) access across all of the resources
> before worrying about C_UD

+1

> - We should get CRUD working on a single resource before we move on

+1. For a specific CRUD application, I'm particularly interested in
trying Biblios (i.e., MARC bib editor) integration via Jangle.

> - "Jangle" is effectively 2 parts, Jangle core (AtomPub interface)
> and Jangle connectors that communicate via JSON and the semantics of
> how library specific resources map to AtomPub semantics

+1.

> - Start with 4 primitive resource types, "Actor", "Collection",
> "Manifestation" (or "Metadata Record" or "Resource"), "Item"

+1

Regards,

Galen

Peter Murray

unread,
Apr 3, 2008, 9:26:43 AM4/3/08
to jangle-...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Apr 2, 2008, at 12:47 PM, Ross Singer wrote:
> - The spec will be for exposing library services to the Atom
> Publishing Protocol

This one isn't a no-brainer for me -- I'd need to think about it a
little more.

> - The first "use case" will be to support the DLF ILS & Discovery
> Interface API (although not to the exclusion of other use cases)

- - - -1 -- That is a huge use case, and I'd almost prefer that the
Jangle effort target those aspects of the DLF work that do not have
clear-cut bindings in the existing suite of standards.

> - We should focus on GET (read) access across all of the resources
> before worrying about C_UD

+1

> - We should get CRUD working on a single resource before we move on

- - - -1

> - "Jangle" is effectively 2 parts, Jangle core (AtomPub interface)
> and Jangle connectors that communicate via JSON and the semantics of
> how library specific resources map to AtomPub semantics

Requires more thinking -- see the first point.

> - Start with 4 primitive resource types, "Actor", "Collection",
> "Manifestation" (or "Metadata Record" or "Resource"), "Item"


+1

On Apr 2, 2008, at 2:10 PM, Ross Singer wrote:
> - All resources have deferenceable URIs with some expectation of
> permanence (i.e. http://jangle.example.org/koha/actors/1234)

+1

On Apr 2, 2008, at 3:42 PM, Ross Singer wrote:
> We really need granular authorization/authentication
> for resources and that needs to be explicit in the spec (and then up
> to the implementor to respect that).

- - - -1 -- not for the first 30-day round.


Peter
- - - --
Peter Murray http://www.pandc.org/peter/work/
Assistant Director, New Service Development tel:+1-614-728-3600;ext=338
OhioLINK: the Ohio Library and Information Network Columbus, Ohio
The Disruptive Library Technology Jester http://dltj.org/
Attrib-Noncomm-Share http://creativecommons.org/licenses/by-nc-sa/2.5/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFH9NsU4+t4qSfPIHIRAtogAJ4793nbTrkFLYJ/N72HCiuWpoSg5QCgmU1O
Q5AWo/Ut9JINCVvBo3sTJ70=
=Z0uc
-----END PGP SIGNATURE-----

Galen Charlton

unread,
Apr 3, 2008, 10:01:57 AM4/3/08
to jangle-...@googlegroups.com
Hi,

On Thu, Apr 3, 2008 at 8:26 AM, Peter Murray <pe...@ohiolink.edu> wrote:
> On Apr 2, 2008, at 3:42 PM, Ross Singer wrote:
> > We really need granular authorization/authentication
> > for resources and that needs to be explicit in the spec (and then up
> > to the implementor to respect that).
>
> - - - -1 -- not for the first 30-day round.

Security considerations ought to be accounted for in the specification
from the start, not added as an afterthought. This particularly
important for Actor resources, and also important for Jangle to be
trusted to mediate CUD operations. That being said, we should of
course keep the security model as simple as possible (but no simpler).

Regards,

Galen
LibLime

Peter Murray

unread,
Apr 3, 2008, 10:17:43 AM4/3/08
to jangle-...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


That is a good point, Galen. I agree that it should be taken into
account, but I'd hope the first round or two would not get burdened
down with a lot of discussion about access management.

If the first round does indeed focus on read (a.k.a. HTTP GET) methods
only, then we would need an authN scheme and a very light-weight authZ
scheme. Higher level authZ needs -- who can edit what under which
conditions -- could be layered on later.


Peter


- --
Peter Murray http://www.pandc.org/peter/work/
Assistant Director, New Service Development tel:+1-614-728-3600;ext=338
OhioLINK: the Ohio Library and Information Network Columbus, Ohio
The Disruptive Library Technology Jester http://dltj.org/
Attrib-Noncomm-Share http://creativecommons.org/licenses/by-nc-sa/2.5/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFH9OcH4+t4qSfPIHIRAtjKAKDH9cuJbP9086QfMCZd3VSKOYS3XwCglQ1R
zEGsu8X0YzKJWzxESpTNNso=
=tK7V
-----END PGP SIGNATURE-----

Ross Singer

unread,
Apr 3, 2008, 11:15:10 AM4/3/08
to jangle-...@googlegroups.com
Ok, since we have our first negative, let me flesh this out some more...

On Thu, Apr 3, 2008 at 9:26 AM, Peter Murray <pe...@ohiolink.edu> wrote:
>
> This one isn't a no-brainer for me -- I'd need to think about it a
> little more.
>

Understandable. The rationale for this decision may need to be
fleshed out a bit more, as well.


>
> > - The first "use case" will be to support the DLF ILS & Discovery
> > Interface API (although not to the exclusion of other use cases)
>
> - - - -1 -- That is a huge use case, and I'd almost prefer that the
> Jangle effort target those aspects of the DLF work that do not have
> clear-cut bindings in the existing suite of standards.
>

Ok, can you go into this a bit more? Granted, my "proposal" might be
misleading. I do not expect Jangle to be 1:1 to the DLF API, merely
as the foundation to which a service that conforms to the API can be
built upon. I have little faith that the vendors will deliver on the
DLF recommendation, but it would be ideal if developers had a
framework (a common API) to be able to build services (or modules)
upon. I see the DLF API as one of those "external modules".

Ross Singer

unread,
Apr 3, 2008, 11:17:48 AM4/3/08
to jangle-...@googlegroups.com
There is part of me that thinks that this should just be relegated to
HTTP (since we're only concerning ourselves with HTTP) and left to the
discretion of the implementor. What I want to make sure, however, is
that we don't limit the options available to implementors and I also
don't want to ignore the importance of this need. Perhaps more than a
spec (for AuthN/AuthZ), a recommendation would be in order here (and
maybe per resource/method).

-Ross.

Ross Singer

unread,
Apr 3, 2008, 11:18:43 AM4/3/08
to jangle-...@googlegroups.com
And as a quick followup to this, I think it should be the
responsibility of the jangle developer to explain how to secure their
application according to the recommendations.

-Ross.

Andrew Nagy

unread,
Apr 3, 2008, 11:23:41 AM4/3/08
to jangle-...@googlegroups.com
On Thu, Apr 3, 2008 at 11:18 AM, Ross Singer <rossf...@gmail.com> wrote:
>
> And as a quick followup to this, I think it should be the
> responsibility of the jangle developer to explain how to secure their
> application according to the recommendations.


Yes - I like this approach. Jangle needs to be a "communication"
framework (the equinox guys can step in and shout about opensrf at
anytime) and therefore very light weight. I really like the approach
that the apache solr folks take in saying that apache solr has no
security or auth features as it is expected that you build that
yourself on top of solr. This makes solr lightweight and a fast mean
screamin machine.

Let's make jangle a very lightweight middleware tool and let the
implementers worry about security, auth, etc.

Andrew

Ross Singer

unread,
Apr 3, 2008, 11:31:52 AM4/3/08
to jangle-...@googlegroups.com
I agree completely with this (although I would argue that Jangle would
be a fair shake more complicated than Solr). That being said, since
we're dealing with sensitive personal data... and, uh, librarians
implementing it (no offense!), I think being explicit on what really
should be secured and how to do it is pretty important.

I guess, in my mind, the Solr developers can be a little more blasee
in their approach since their audience is a little different (and
generally more generic).
-Ross.

Andrew Nagy

unread,
Apr 3, 2008, 11:37:23 AM4/3/08
to jangle-...@googlegroups.com
On Thu, Apr 3, 2008 at 11:31 AM, Ross Singer <rossf...@gmail.com> wrote:
>
> I agree completely with this (although I would argue that Jangle would
> be a fair shake more complicated than Solr). That being said, since
> we're dealing with sensitive personal data... and, uh, librarians
> implementing it (no offense!), I think being explicit on what really
> should be secured and how to do it is pretty important.

Im just saying i like the approach of designing the system to be
lightweight and fast and not over complicate it. Just using Solr as an
example - not as a comparison. We need to define the scope of what
Jangle will do and what it won't do - but keep simplicity and
"lightweight-ness" in mind.

Andrew

Ross Singer

unread,
Apr 3, 2008, 11:44:22 AM4/3/08
to jangle-...@googlegroups.com
We are on the same page :)

Galen and I were just discussing off-list how this would really have to work:

Authentication mechanism for client to talk to Jangle and Jangle to
talk to connectors. Unauthorized clients shouldn't be able to talk to
Jangle (at least for some data, like patrons) and, likewise,
unauthorized Jangle cores shouldn't be able to talk to Jangle clients.

Then there's a more tricky internal auth (and I'm not sure if this is
AuthN or AuthZ in this case) of how to expose patron data to the
appropriate parties (i.e., I can see *my* profile) and block it from
others (I can't see *your* profile).

Again, I think the details need to be left to the implementor but the
requirement needs to be in the spec.

-Ross.

Peter Murray

unread,
Apr 3, 2008, 11:44:19 AM4/3/08
to jangle-...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

How many more acronyms can be crammed into the subject?

On Apr 3, 2008, at 11:15 AM, Ross Singer wrote:
>>> - The first "use case" will be to support the DLF ILS & Discovery
>>> Interface API (although not to the exclusion of other use cases)
>>
>> - - - -1 -- That is a huge use case, and I'd almost prefer that the
>> Jangle effort target those aspects of the DLF work that do not have
>> clear-cut bindings in the existing suite of standards.
>
> Ok, can you go into this a bit more? Granted, my "proposal" might be
> misleading. I do not expect Jangle to be 1:1 to the DLF API, merely
> as the foundation to which a service that conforms to the API can be
> built upon. I have little faith that the vendors will deliver on the
> DLF recommendation, but it would be ideal if developers had a
> framework (a common API) to be able to build services (or modules)
> upon. I see the DLF API as one of those "external modules".


I had interpreted the proposal as creating a 1-to-1 binding with the
proposed functions in the proposed DLF API. So I think I'm still not
clear on the proposal...pieces of the DLF API could be implemented
using NCIP, SRU, and other standards. Where would Jangle fit into
that mix?


Peter


- --
Peter Murray http://www.pandc.org/peter/work/
Assistant Director, New Service Development tel:+1-614-728-3600;ext=338
OhioLINK: the Ohio Library and Information Network Columbus, Ohio
The Disruptive Library Technology Jester http://dltj.org/
Attrib-Noncomm-Share http://creativecommons.org/licenses/by-nc-sa/2.5/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFH9PtW4+t4qSfPIHIRArIxAJ0STdtTj9lM/9tBqakdjvnwcgXzQwCePD5I
DqgJyqKXf9sf3K2j/xxdgIY=
=A29E
-----END PGP SIGNATURE-----

Ross Singer

unread,
Apr 3, 2008, 11:56:58 AM4/3/08
to jangle-...@googlegroups.com
Right. The problem with the DLF proposal as it currently stands is
that none of those standards exist in most ILSes (with the possible
exception of NCIP and, I think we can all agree, is spotty,
inconsistent and probably non-interoperable). So, this means the
vendors would need to not only get on board with NCIP (which they've
been dragging their feet on for seven years), but also OAI-PMH and SRU
(when most of them don't even have a decent Z39.50 server). The 'item
status availability' service isn't even mapped to an existing
standard, so who knows what would happen with that.

Where I see Jangle is fitting is *behind* these services. It would be
a common API to then build an OAI-PMH service on top of. We'd only
have to build one, and all ILSes (or reserves systems or whatever)
would benefit from it.

The real winner that I see here would be NCIP (eh, and I'm speaking in
relative terms), since I think the economy of scale would enable us to
focus on a Jangle implementation rather than a bunch of inconsistent
backend interfaces.

-Ross.

Peter Murray

unread,
Apr 3, 2008, 11:59:49 AM4/3/08
to jangle-...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Apr 3, 2008, at 11:44 AM, Ross Singer wrote:
> Authentication mechanism for client to talk to Jangle and Jangle to
> talk to connectors. Unauthorized clients shouldn't be able to talk to
> Jangle (at least for some data, like patrons) and, likewise,
> unauthorized Jangle cores shouldn't be able to talk to Jangle clients.

+1

> Then there's a more tricky internal auth (and I'm not sure if this is
> AuthN or AuthZ in this case) of how to expose patron data to the
> appropriate parties (i.e., I can see *my* profile) and block it from
> others (I can't see *your* profile).

+1


Peter


- --
Peter Murray http://www.pandc.org/peter/work/
Assistant Director, New Service Development tel:+1-614-728-3600;ext=338
OhioLINK: the Ohio Library and Information Network Columbus, Ohio
The Disruptive Library Technology Jester http://dltj.org/
Attrib-Noncomm-Share http://creativecommons.org/licenses/by-nc-sa/2.5/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFH9P724+t4qSfPIHIRAjQIAJ46KALlV922GJGAAeHMx9WrZTNOEgCgqtZR
COk3IGQeu9YeVkFLLXkEoC0=
=BPE+
-----END PGP SIGNATURE-----

Peter Murray

unread,
Apr 3, 2008, 12:06:56 PM4/3/08
to jangle-...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ah! Now all becomes clearer. Encouraging the vendors to support a
Jangle suite relieves them of having to provide separate NCIP, OAI-
PMH, and SRU services, yes?


Peter

iD8DBQFH9QCg4+t4qSfPIHIRAkRnAJ91ZPfFdglyqENulOaXYfx2qHb4ogCfXmxC
dqSedQXcqecQQIm2Y5wsu7k=
=5pNp
-----END PGP SIGNATURE-----

Ross Singer

unread,
Apr 3, 2008, 12:12:10 PM4/3/08
to jangle-...@googlegroups.com
Yes. Or circumventing the vendors and relying on the geeks that are
saddled with their products would be easier if we're working towards a
more consistent framework (I note the only vendors currently on this
list are Talis, Equinox, LibLime and Bibliocommons -- not exactly
tremendous market share). "If I make a Jangle connector, I get all
this other stuff, and I can start using GData clients to access it?
But I really *wanted* to make an OpenURL interface specific to my III
ILS!"

-Ross.

Mike Rylander

unread,
Apr 3, 2008, 12:59:37 PM4/3/08
to jangle-...@googlegroups.com
On Thu, Apr 3, 2008 at 11:44 AM, Ross Singer <rossf...@gmail.com> wrote:
>
> We are on the same page :)
>
> Galen and I were just discussing off-list how this would really have to work:
>
> Authentication mechanism for client to talk to Jangle and Jangle to
> talk to connectors. Unauthorized clients shouldn't be able to talk to
> Jangle (at least for some data, like patrons) and, likewise,
> unauthorized Jangle cores shouldn't be able to talk to Jangle clients.

I think something got lost in translation here. Could you give
examples? The terminology is still ... new. ;)

>
> Then there's a more tricky internal auth (and I'm not sure if this is
> AuthN or AuthZ in this case) of how to expose patron data to the
> appropriate parties (i.e., I can see *my* profile) and block it from
> others (I can't see *your* profile).
>

IMO, I think that distinction is up to the backing ILS. To use the
patron data example, user X (a staff member) may be able to see some,
but not all, patron records. That granularity is surely outside the
scope of Jangle to manage, but by providing a robust exception
framework whereby details of a permission-based denial can be passed
back in some normalized fashion, both Jangle and the ultimate client
can explain to the user why function Y was not performed.

I guess what I'm getting at is that there needs to be a codified
failure mechanism that allows information beyond basic HTTP-modeled
error codes. Perhaps we can use the body of the response to supply
the information to the client, and the status code (403, etc) as the
logical baseline trigger.

> Again, I think the details need to be left to the implementor but the
> requirement needs to be in the spec.
>

The requirement, and a general way of reporting details in the case of
a permission failure.

--miker

> -Ross.
>
>
>
> On Thu, Apr 3, 2008 at 11:37 AM, Andrew Nagy <asn...@gmail.com> wrote:
> >
> > On Thu, Apr 3, 2008 at 11:31 AM, Ross Singer <rossf...@gmail.com> wrote:
> > >
> > > I agree completely with this (although I would argue that Jangle would
> > > be a fair shake more complicated than Solr). That being said, since
> > > we're dealing with sensitive personal data... and, uh, librarians
> > > implementing it (no offense!), I think being explicit on what really
> > > should be secured and how to do it is pretty important.
> >
> > Im just saying i like the approach of designing the system to be
> > lightweight and fast and not over complicate it. Just using Solr as an
> > example - not as a comparison. We need to define the scope of what
> > Jangle will do and what it won't do - but keep simplicity and
> > "lightweight-ness" in mind.
> >
> >
> >
> > Andrew
> >
> > >
> >
>
> >
>

--
Mike Rylander
| VP, Research and Design
| Equinox Software, Inc. / The Evergreen Experts
| phone: 1-877-OPEN-ILS (673-6457)
| email: mi...@esilibrary.com
| web: http://www.esilibrary.com

Mike Rylander

unread,
Apr 3, 2008, 1:02:20 PM4/3/08
to jangle-...@googlegroups.com
On Thu, Apr 3, 2008 at 11:23 AM, Andrew Nagy <asn...@gmail.com> wrote:
>
> On Thu, Apr 3, 2008 at 11:18 AM, Ross Singer <rossf...@gmail.com> wrote:
> >
> > And as a quick followup to this, I think it should be the
> > responsibility of the jangle developer to explain how to secure their
> > application according to the recommendations.
>
>
> Yes - I like this approach. Jangle needs to be a "communication"
> framework (the equinox guys can step in and shout about opensrf at
> anytime) and therefore very light weight. I really like the approach

HA! :)

> that the apache solr folks take in saying that apache solr has no
> security or auth features as it is expected that you build that
> yourself on top of solr. This makes solr lightweight and a fast mean
> screamin machine.
>
> Let's make jangle a very lightweight middleware tool and let the
> implementers worry about security, auth, etc.
>

I'll echo Ross' comment further down, and say that I think we really
do need to take security into account as a first tier priority for
certain parts of the API from the start, and lay out a reasonable and
general plan on how to implement that security.

Reply all
Reply to author
Forward
0 new messages