Hey Ross, et alles,

I'm trying to set-up "PHP Jangle," and have checked out the code here:

  http://code.google.com/p/phpjangle/

I'm looking at the spec and the code at the same time, so not totally sure even what I'm looking at yet.

It seems to me, though, that at least some of what is here:

   http://jangle.googlecode.com/svn/trunk/PHPCore/

Is not over on the phpjangle code site.  In particular, the index.php access point.

Do you have time to (briefly) outline what is finished and what still needs to be ported over?

Thanks,

--Dave

==================
David Walker
Library Web Services Manager
California State University
http://xerxes.calstate.edu

Hi David!

Good questions -- as you can see from SVN, the last activity at
phpjangle was in May of last year, so I'm going to have to knock some
cobwebs loose to answer these.

Looking at Services_Jangle, it looks like I got as far as writing
classes to assist in developing connectors, but not cores (which I'll
explain in a minute).  Looking at the various bits and pieces of
PHP-based connectors I've written over the last couple of years, I'm
not exactly sure I've actually used this (the SVN timestamp also
roughly coincides to when I started in earnest on the Alto connector,
which pushed my multi-languages support initiative to the backseat).

I will be happy to do either:
1) Fix anything you might find wrong with it
2) Add you as a committer.

I'll also write a brief HOWTO use it this afternoon.  I can tell you
its purpose, though, to see if it fits what you're looking for.

Basically it's a set of classes to construct the Jangle connector JSON
responses.  If you need to output a Jangle 'feed' responses, for
example, you'd do something like this: (warning my PHP is really
rusty)

$connector = new Services_Jangle::Jangle_Connector($http_request, $config);
$feed = $connector->createFeed();
$feed->setTotalResults(1);
$item = new Services_Jangle::Jangle_Feed_Item('http://example.edu/ex/resources/1234');
$item->title = "Title of Resource";
$item->setContent($file_marc_record->toXML());
$feed->addDataItem($item);

header("Content-type: application/json");
echo($feed->toJSON());

etc.  If there are less verbose ways to accomplish the same goal, I'm
happy to take any recommendations.  My idea for Services_Jangle,
though, was to keep it pretty low level and then build any sort of
DSLs on top of it (again, in the paving cowpaths vein).

Now, about PHPCore vs. this -- Jangle (the spec) requires two distinct
components:  the connector and core.  In reality, I expect these to be
both bundled in the same service most of the time (this is the
intention with the Alto connector, for example), but any Core must be
able to consume any connector (that it has permission to, of course)
and any connector must be available to any Core, so technically, you
can't just release a connector that doesn't expose the connector API
at all.  The current crop of Jangle apps were designed to highlight
this separation of concerns.  That being said, the design of the Alto
connector was done in a way that the same code will be able to output
the connector /or/ Core APIs, since there's no point in generating and
parsing the JSON for stuff that's running on the exact same server in
the same Rails application.  But, since that's not implemented, yet,
SWWHEP is using the PHPCore to serve Alto.  That agnosticism, despite
the upfront development burden of having to provide two independent
components, makes it somewhat more versatile.

Taking SWWHEP's situation as an example:
They are a consortium of three institutions:  one uses Voyager, one
uses Horizon, one uses Alto.  Assuming magical future where Jangle
connectors existed for all three of these ILSes, SWWHEP could run one
Jangle core centrally access all three ILSes using something like:

http://jangle.swwhep.ac.uk/swansea/resources/1234
http://jangle.swwhep.ac.uk/trinity/items/5678
http://jangle.swwhep.ac.uk/swansea-met/actors/9012

etc. rather than having to have completely different configurations
for all institutions.

Does that help clear anything up?

Thanks,
-Ross.

I'm pretty sure I understand the difference between the core and the connectors, and appreciate the need to have each independent of the other.

Is the PHP 'core' here more or less done?

  http://jangle.googlecode.com/svn/trunk/PHPCore/

Would you prefer that it live there, versus in the phpjangle svn repository?

--Dave

==================
David Walker
Library Web Services Manager
California State University
http://xerxes.calstate.edu
________________________________________
From: jangle-discuss@googlegroups.com [jangle-discuss@googlegroups.com] On Behalf Of Ross Singer [rossfsin...@gmail.com]
Sent: Friday, February 05, 2010 9:14 AM
To: jangle-discuss@googlegroups.com
Subject: Re: [jangle-discuss] PHP Jangle

Hi David!

Good questions -- as you can see from SVN, the last activity at
phpjangle was in May of last year, so I'm going to have to knock some
cobwebs loose to answer these.

Looking at Services_Jangle, it looks like I got as far as writing
classes to assist in developing connectors, but not cores (which I'll
explain in a minute).  Looking at the various bits and pieces of
PHP-based connectors I've written over the last couple of years, I'm
not exactly sure I've actually used this (the SVN timestamp also
roughly coincides to when I started in earnest on the Alto connector,
which pushed my multi-languages support initiative to the backseat).

I will be happy to do either:
1) Fix anything you might find wrong with it
2) Add you as a committer.

I'll also write a brief HOWTO use it this afternoon.  I can tell you
its purpose, though, to see if it fits what you're looking for.

Basically it's a set of classes to construct the Jangle connector JSON
responses.  If you need to output a Jangle 'feed' responses, for
example, you'd do something like this: (warning my PHP is really
rusty)

$connector = new Services_Jangle::Jangle_Connector($http_request, $config);
$feed = $connector->createFeed();
$feed->setTotalResults(1);
$item = new Services_Jangle::Jangle_Feed_Item('http://example.edu/ex/resources/1234');
$item->title = "Title of Resource";
$item->setContent($file_marc_record->toXML());
$feed->addDataItem($item);

header("Content-type: application/json");
echo($feed->toJSON());

etc.  If there are less verbose ways to accomplish the same goal, I'm
happy to take any recommendations.  My idea for Services_Jangle,
though, was to keep it pretty low level and then build any sort of
DSLs on top of it (again, in the paving cowpaths vein).

Now, about PHPCore vs. this -- Jangle (the spec) requires two distinct
components:  the connector and core.  In reality, I expect these to be
both bundled in the same service most of the time (this is the
intention with the Alto connector, for example), but any Core must be
able to consume any connector (that it has permission to, of course)
and any connector must be available to any Core, so technically, you
can't just release a connector that doesn't expose the connector API
at all.  The current crop of Jangle apps were designed to highlight
this separation of concerns.  That being said, the design of the Alto
connector was done in a way that the same code will be able to output
the connector /or/ Core APIs, since there's no point in generating and
parsing the JSON for stuff that's running on the exact same server in
the same Rails application.  But, since that's not implemented, yet,
SWWHEP is using the PHPCore to serve Alto.  That agnosticism, despite
the upfront development burden of having to provide two independent
components, makes it somewhat more versatile.

Taking SWWHEP's situation as an example:
They are a consortium of three institutions:  one uses Voyager, one
uses Horizon, one uses Alto.  Assuming magical future where Jangle
connectors existed for all three of these ILSes, SWWHEP could run one
Jangle core centrally access all three ILSes using something like:

http://jangle.swwhep.ac.uk/swansea/resources/1234
http://jangle.swwhep.ac.uk/trinity/items/5678
http://jangle.swwhep.ac.uk/swansea-met/actors/9012

etc. rather than having to have completely different configurations
for all institutions.

Does that help clear anything up?

Thanks,
-Ross.

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

*Whew*.  Seriously -- this is one of the harder aspects of jangle that
people looking at it have to reconcile.

Would you settle for "working" if not technically "done"?  Like I
said, it's what SWWHEP is currently using.  There are two outstanding
"issues" with it:
1) Authentication headers from a Jangle connector do not get passed
along (instead, the connector just fails the authentication process)
-- this is a high priority TODO.
2) PEAR_Cache is a requirement for PHPCore to work, but it's unused.
This is mainly because the existing crop of connectors don't support
ETags, yet (they need to, it's just complicated to figure out when a
resource has changed without going through the entire process it takes
to serialize the JSON, anyway).

Not sure -- the phpjangle project was intended to host the PEAR
compliant Jangle classes.  Again, I'm going to defer to actual PHP
users.  What would *you* find most useful?  In theory, the phpjangle
classes will be a dependency of PHPCore (eventually), but not
necessarily the other way around.

If nothing else, PHPCore might be useful as a download from phpjangle, eh?

Thanks,
-Ross.

Or even links from each project to the other so it's easy to find all the pieces.  Might get annoying to have to update the same file in two places, but if there's a clear link from one to the other, it doesn't really matter where it lives.

- Demian

Sure -- I mean, it's not terribly user friendly that the only way to
access either is via SVN at the moment, anyway.

I have no problem making the "download" only at phpjangle.  Then
again, I have no problem moving the sources for the Core there,
either.  I am a reed in the wind to your wishes, folks.

-Ross.

I say move the current PHP Core to the phpjangle svn repo.

Are you using any PEAR libraries in the current Jangle PHP code?  Are you wedded to the idea of making this a PEAR package?

--Dave

==================
David Walker
Library Web Services Manager
California State University
http://xerxes.calstate.edu
________________________________________
From: jangle-discuss@googlegroups.com [jangle-discuss@googlegroups.com] On Behalf Of Ross Singer [rossfsin...@gmail.com]
Sent: Friday, February 05, 2010 10:49 AM
To: jangle-discuss@googlegroups.com
Subject: Re: [jangle-discuss] PHP Jangle

Sure -- I mean, it's not terribly user friendly that the only way to
access either is via SVN at the moment, anyway.

I have no problem making the "download" only at phpjangle.  Then
again, I have no problem moving the sources for the Core there,
either.  I am a reed in the wind to your wishes, folks.

-Ross.

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

Ok, so I'll take that as a +1
No, the existing PHP-based connectors (OpenBiblio, Res. Direct) all
predate this work.

I am not wedded to it, no.  I never had the idea of actually
submitting it to PEAR, but I was asked (per:
http://groups.google.com/group/jangle-discuss/browse_thread/thread/72...)
to make it PEAR compliant to make it easier for somebody to step in
and work with it.

Again, I personally have no dog in this fight.

-Ross.

Debates about relying on PEAR dependencies aside, it certainly makes sense to try to comply with public standards, and the PEAR coding standards are pretty widespread, so working with those sounds like a good idea to me.

- Demian

Okay, so it sounds like both Andrew (from that earlier email thread) and Damien would like for php-jangle to  follow PEAR coding conventions.  I'm not familiar with those (I don't use PEAR), but that sounds good.

But no one is particularly wedded to it being an actual PEAR package.

So Connector.php has at the top:

  require_once 'PEAR.php';

Seems like I can safely comment this out in my local copy, and everything will still work.

--Dave

==================
David Walker
Library Web Services Manager
California State University
http://xerxes.calstate.edu
________________________________________
From: jangle-discuss@googlegroups.com [jangle-discuss@googlegroups.com] On Behalf Of Demian Katz [demian.k...@villanova.edu]
Sent: Friday, February 05, 2010 11:22 AM
To: jangle-discuss@googlegroups.com
Subject: RE: [jangle-discuss] PHP Jangle

Debates about relying on PEAR dependencies aside, it certainly makes sense to try to comply with public standards, and the PEAR coding standards are pretty widespread, so working with those sounds like a good idea to me.

- Demian

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

I think you're probably right.  Let me know and if it still works,
I'll update trunk.

-Ross.

Great!  For the most part, the standards are common sense things you are probably already doing anyway, but if you want to take a look for reference, here's the link:

http://pear.php.net/manual/en/standards.php

- Demian