…
Together with a team of technicians to keep them running. (By way of
fair disclosure, I guess I should say that I’m not exactly a fan of
Java. …
Me neither. Even newer languages like Scala, while nice, are a PITA to
deal with in terms of building, classpaths, etc., etc.
…
XML-RPC is rather more heavy-weight that what I’m used to dealing
with, but stripping out implementation details, what’s the request,
and what’s the response?
Request
Id (for sessioned systems)
Method (string)
Parameter (string or object list)
Response
Id (for sessioned systems)
Response (string)
At least that’s what the little demo uses.
I guess to the degree that I’ve done any (limited) server stuff, it’s
of the more RESTful (Django, web.py, etc.) kind, where you might have
a URI like this:
http://someservice.org/citeproc/bibliography
… which gets bound to a method like “run_bibliography”, which takes
a series of parameters, and returns a response.
So what I meant by my question was, what should be the …
a) methods
b) parameters
c) response
…?
Ah. There are four commands at the moment:
method: setStyle
parameter: serialized XML of CSL style
response: “Set style OK”
method: insertItems
parameter: list of data items
response: “Insert items OK”
method: makeCitationCluster
parameter: list of data items
response: formatted string data
method: makeBibliography
parameter: none
response: formatted string data
There will be at least two more methods, “removeItems” (for removing
items from the processor’s persistent store and adjusting sort
sequence and disambiguation configs) and “itemInfo”, for a list of all
item variables used by the style – this will help the application be
more efficient about DB retrievals if it wants to be.
The API for data items basically follows csl.rnc, plus a breakdown of
names to smaller elements.
This sounds very similar to our Zotero API, so it should fit in nicely. One
problem (and I haven’t looked at the code yet, so this may actually be
resolved somewhere): how does one specify page numbers (or other
citation-specific information) for different citations in
makeCitationCluster? Our current API has a separate CitationItem class to
account for this, which includes a reference to the item object as well as
prefix, suffix, locator, and suppress author parameters.
This still needs to be stirred in. At the start, I just blithely
thought I would bang those details onto the individual data items,
since within the processor they’re treated as disposable data. If the
data items have a life elsewhere, though, that would mean added cost
for cloning everything, which now seems like not such a good idea. It
might be better to extend the internal interfaces, and treat them as a
paired package throughout the code.
I haven’t gotten to this yet in part because locators requires page
numbers, and numbers require range awareness, and implementing range
awareness affects the output queue machinery, which was based on the
happy and reckless assumption that everything could be string-ified as
soon as it was queued for rendering. I’m now in the process of fixing
that (it won’t be pretty, but the ugliness will all be in one place).
Once that’s out of the way, I’ll come up against locators and the
interface problem. At decision time, I’ll give a shout.
Frank
