Zu dem Beispiel oben aus der Grafik Titel “Programming Web Services with Perl”. Der hat im KUG und bei uns die ISBN “978-0-596-00206-0″ bzw. 10-stellig “0-596-00206-8″ und das E-Jahr 2003 bzw. 2002, in PaperC wird ueber die Suchfunktion mit der 10-stelligen ISBN der Titel mit E-Jahr 2007 gefunden (ebenfalls in Englisch und 1. Auflage). Als ISBN wird dort angegeben “9780596516413″. Mit der 13-stelligen ISBN findet die Suchfunktion nichts (wurde ja auch oben schon beschrieben).
Über die API (deren Doku ich so verstanden habe, dass sie generell mit der 13-stelligen ISBN zufrieden ist, was uns sehr entgegenkommen würde) erhalte ich weder mit der 10- noch mit der 13-stelligen ISBN einen Treffer.

Weiss jemand Rat?

Leonhard Maylein

wir haben jetzt zwei Funktionen öffentlich Dokumentiert. http://blog.paperc.de/api

Das ist bei weitem noch nicht alles, wir werden in den nächsten Wochen noch an öffentlichen Funktionen nachlegen.

Ich muss dir für deine Inspiration und einen Erfindergeist danken. Das ist total cool!
Wir arbeiten ausgehend von deiner Idee in den nächsten Woche an einem “Button Widget”, welches die Einbindung einfach auf der Client-side per HTML ermöglicht.

Sobald dieses fertig ist, werd ich mich gleich mal direkt bei dir melden.

Grüße Lukas

Zunächst einmal stört die von uns verwendete SessionID im URL dabei. Ein Ausweg wäre die Verwendung von Cookies, mit denen ich bereits experimentiere. Allerdings sind auch die nicht vollkommen ohne “Nebenwirkungen” – einige Nutzer reagieren manchmal allergisch darauf Über entsprechende Add-Ons ist es im Firefox inzwischen aber anscheinend möglich, mehrere Sitzungen in verschiedenen Tabs zu nutzen, die alle ihre eigenen Cookies verwalten. Das war lange Zeit ein Problem. Aus Gründen der Web-Sicherheit müsste man eigentlich beides machen, spezielle IDs im URL und Cookies…

Darüber hinaus spiegelt sich im URL zusätzlich unsere Lastverteilung auf mehrere Server wider. Am Beginn einer jeden Sitzung wird intelligent der Server bestimmt, der am wenigsten Recherchelast hat (und bei dem gewisse Vitalitäts-Test erfolgreich sind) und der Nutzer dann dorthin weiter geleitet. Hier müsste man stattdessen nun einen intelligenten Proxy vorschalten (z.B. mit der Adresse kug.ub.uni-koeln.de), der sich die auf den KUG-Servern (kug1, kug2, ..) vergebenen SessionID’s merkt und alle Anfragen dann transparent an den “richtigen” Server weiterleitet. Im schlimmsten Fall würde darunter jedoch die relative Autonomie der verschiedenen KUG-Server leiden, zu der in unserem Setup auch das Session-Management gehört. Daher streben wir hier eine transparente Gesamtlösung in Form eines Clusters, Grids, … (insert your favourite buzzword here) an, bei der die derzeitige – auf der Server-Autonomie beruhende – Skalierbarkeit und Ausfallsicherheit weiterhin gewahrt bleibt. Das ist aber ein größerer Umbau, der sicherlich noch einige Zeit braucht.

Während woanders noch darüber nachgedacht wird, ob und wie man den Dienst PaperC in den eigenen Katalog integrieren kann, zeigt Oliver Flimm mit dem KUG wie man es macht, wenn man es kann… Um unseren Nutzern die Vorteile von PaperC schon jetzt a….

vielen Dank für die schnelle und geniale Umsetzung.

Ein kleinen Hinweis habe ich: PaperC steht für Pay-Per-Copy (nicht Pay – Per – See). Denn das Lesen von Fachbüchern bei uns ist grundsätzlich kostenfrei.

Vielen Dank nochmal und viele Grüße.

Christoph Harnoth
PaperC

wir freuen uns RIESIG! Ein toller Schritt und wir befürworten dies zu 100 Prozent!

Sag Bescheid auf @paper_c oder kontaktier mich direkt @Overbryd falls du Fragen hast.

API Doc kommt sofort, *tippel* *tipp*

Grüße Lukas