Hi everybody
thanks for all of the infos. I’ll use this message to respond to all of them at once so that the discussion does not fragment too much.
My only JS experience is in the Rhino environment in which citeproc-js
is being written. My only server experience is with fairly primitive
stuff in Apache and fairly sophisticated stuff in Plone; I’m not a
very useful source of advice on PHP integration, I’m afraid. From
what I’ve heard in passing, though, I’d guess that tomcat would be an
appropriate server platform for it, since it would allow you to
instantiate a citeproc-js formatter for the duration of a session, as
it’s designed to work. I don’t think running it from shell for each
transaction would be a happy experience; a citeproc-js formatter has
to be built (compiled, sort of) before it’s run. The runtime instance
should be fast, but the build stage will be slow, and you would
probably run into latency issues fairly quickly.
Frank, the java dependency is exactly the same problem that I had when I first tried Bruce’s XSLT2 implementation two years ago and it was dependent on the Saxon XSLT2 processor. The problem is that I want my application to run even on small servers (like a thinly-powered virtual server) - that’s the whole point of sticking with PHP - , which excludes Java Application Servers like Tomcat etc. I wonder, though, aren’t there any standalone binary Javascript interpreters that one could use?
This sort of goes back to my common API question from awhile back.
Perhaps this is a way to back into this. To wit, I’ve created a wiki
page for this:
https://apps.sourceforge.net/trac/xbiblio/wiki/CSLDeployment
Bruce, that’s exactly what we need! Thanks. I’ll test all of the solutions posted there and will give you feedback.
So for JS, there’s two options: client and server.
I’m not sure the use cases for the client end, but I’d expect that it
would work roughly like what you see in my pseudo python version,
except that the data would get loaded as JSON, and perhaps also via an
AJAX server call.
So I’d expect a function to run, say, a bibliography, but that you’re
not feeding it a traditional object (e.g. class instance), but rather
a JSON data structure.
Bruce
Yes, I’d be interested in that, too. This would solve the latency issues. I have a bibliography application which keeps the currently selected bibliographic data in memory on the client anyways. Instead of the round trip to the server, the bibliography could be generated on-the-fly in the browser, written into a new window (or the system clipboard, if supported).
Actually here you can find a minimal example:
http://code.haskell.org/citeproc-hs/docs/Text-CSL.html#2
together with the haskell implementation API.
If you save it as test.hs, you can run it with:
runhaskell test.hs
or compile it to native code with:
ghc --make test.hs
and run
./test
…
You are right but, and now I’m speaking only for the Haskell code, it
is still immature and subject to rapid development. While I’m
documenting the code I need the stuff to stabilize a bit before
writing end-user documentation (otherwise it would become obsolete
very shortly).
Anyway I’m really willing to help you if you want.
Andrea, thank you. My problem is that I would need a binary that I can configure with command-line options. I don’t know Haskell, so I cannot write it myself. Maybe this would be a useful addition to your library that would not need much documentation? Something that can be compiled on each platform and then called like
citeproc-hs --style apa.cls --infile myreferences.txt --bibdata mybibdb.bib --format bibtex --outfile bibliography.html --format html
or something like this? The command line parameters would not need to change at all even when you refactor your code.
I am certainly encouraged re. the remarks on the
javascript/python/haskell implementations that came in response to
your query. Ideally, we’ll get a native citeproc-php eventually.
The haskell implementation, while not perfect, works with pandoc very
well. It is fairly trivial to use exec() on a server with these tools
if you don’t mind these “heavy” dependencies. I’ve done this, but
haven’t released anything: we don’t want our webapp to be dependent on
these (it is distributed, rather than centrally hosted).
Rick, this is exactly what I want to do. The Haskell impementation compiled as a binary would probably be very fast (although I have no idea how that compares to python or ruby). And we might not need a php-only citeproc at all (except of course in situations where PHP is prevented from calling executables for security reasons).
I think Matthias and I had kicked around the idea of having a central
server that ran pandoc+citeproc-hs & bibutils in order to process
citations for other webapps. Perhaps it is still a reasonably good
idea to have some kind of central server for this in the short-term
(especially if the more-mature javascript code can be used
(server-side) instead).
This would of course be fabulous, except that you probably do not want other people to use your bandwith and CPU to process their bibliographies? 
It could be limited by distributing API keys (or you might want to make it a subscription service).
Ron Jerome mentioned he’d made some progress on a php version modeled
more on the python and ruby versions than the earlier Zotero approach.
I think he managed to get a CSL style parsed into a PHP object. But a)
that’s not actually the hard part (it’s the processing functions), and
b) he got distracted by other stuff. Would be good to get him to put
this up on GitHub or something.
Of course, I’d be thrilled to have a php-only implementation since that I what I am fluent in. But as I said, maybe it would be enough for the start to write a php-bridge to one or more of the other implementations.
Again, thanks for all of your suggestions, and I am happy to try out everything that you throw my way.
Christian–
View this message in context: http://n2.nabble.com/Using-citeproc-implementation-for-third-party-applications-tp2603902p2610093.html
Sent from the xbiblio-devel mailing list archive at Nabble.com.
