[OPEN-ILS-DEV] OPAC (was: Planning for Evergreen development, post 2.0)

[Joe Atzberger]

On Fri, Jan 21, 2011 at 11:53 AM, Dan Scott <dan at coffeecode.net> wrote:

> A TT2-based OPAC will call the same OpenSRF APIs, but via Perl, and as
> the OPAC would probably be hosted in the same rack (if not on the exact
> same server) as the rest of the Evergreen stack, all of the calls it
> would make would not have the same latency issues (browser -> server ->
> browser) and concurrency issues (browsers typically allow 4 concurrent
> requests per host).
>

Actually, these numbers still vary considerably between broswers, browser
versions, browser configurations, persistent vs. non-persistent connections,
and HTTP1.0 vs HTTP1.1:

http://www.stevesouders.com/blog/2008/03/20/roundup-on-parallel-connections/


Notably, IE8 and FF3 bump up to 6 concurrent.  Relevant local configs
include:

IE: MaxConnectionsPerServer
IE: MaxConnectionsPer1_0Server
FF: network.http.max-persistent-connections-per-server
FF: network.http.max-connections-per-server


If you jack up these values arbitrarily, you might trip network security
devices that regard such behavior as aggressive.

The new defaults will produce more bursty multi-connection load, seemingly
adding cost/risk to using Apache's Pre-Fork model.  Can someone with a
longer view remind me if there are chunks we consider to be
mod_perl-thread-unsafe or are we just trying to get through as much
initialization as possible up front?

Also, whatever we expect to be usable on a mobile (iOS, Android, etc.)
device will have to behave well without the massive concurrency.



> One of the tacks I had been taking in the social work was to enable
> results to be returned as either Activity Streams XML or plain HTML. If
> we take a similar approach with the new OPAC and enable a given URL to
> resolve as either plain HTML or JSON, then that could make integration
> much simpler for other discovery layers. For example (making up a
> template URL rather than the current primarily GET param-based
> approach):
>

This approach definitely seems to me to be the most robust and extensible.
 The HTTP headers (for MIME type) are going to matter though.

On a separate point....

On Tue, Jan 25, 2011 at 7:52 AM, Rayner, June <raynerj at einetwork.net> wrote:

> We've been pondering your comment below.   What if the OPAC is not in the
> same rack as the Evergreen stack?   Maybe it's hosted at another datacenter
> entirely?


Both performance and manageability would be predictably degraded.

--joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20110126/0277a958/attachment-0001.htm