[OPEN-ILS-DEV] Which OpenSRF gateway should I use?

[Bill Erickson]

On Wed, Sep 21, 2016 at 1:01 PM, Mike Rylander <mrylander at gmail.com> wrote:

> On Wed, Sep 21, 2016 at 11:51 AM, Bill Erickson <berickxx at gmail.com>
> wrote:
> >
> > On Wed, Sep 21, 2016 at 10:44 AM, Bill Erickson <berickxx at gmail.com>
> wrote:
> >>
> >>
> >> /osrf-http-translator provides a lower level OpenSRF API and supports
> >> streaming responses, but its use is no longer encouraged, because the
> >> underlying mechanism (multipart/x-mixed-replace) is deprecated and only
> >> works with our old version of XULRunner.  This interface will likely be
> >> deprecated along with the XUL client.
> >>
> >
> > Couple of additional comments for those following along...
> >
> > 1. The multipart/x-mixed-replace part of the translator only affects its
> > ability to stream results.  Without this, it's less efficient / fast, but
> > still works.  You just can't use it for API calls that return large
> result
> > sets or for real-time use of individual results.  The OpenSRF API/session
> > support works regardless.
> >
> > 2. Various HTML interfaces outside of the XUL client proper (primarily
> ACQ
> > and admin UI's) use the translator.  All of these would have to be
> ported to
> > websockets before we could consider deprecation.
> >
>
> Meaning, in the end, it'll be a while before the translator goes away,
> or is even deprecated except for streaming.
>
> In addition to the core users, it's simpler (admin- and code-wise) on
> both ends than WebSockets for little things and has the benefit of
> being able to supply transactional semantics even in a clustered
> environment, which I don't think our WebSockets implementation can do
> today (though, if it can, please do correct me!).
>

Clustered transactions should work much the same way with Websockets with a
few caveats.

1. Apache KeepAlive does not affect WS connections, so clients will not be
required to bounce between Apache servers mid-session after a (default) 1
second timeout.  There is a WS idle timeout setting, but it's intended to
drop clients after minutes of inactivity, not seconds.

2. If a client is disconnected from an Apache WS backend, it will connect
to another Apache backend automatically and should be able to resume its
transaction (for "migratable" sessions), the same as an HTTP translator
client.  At this point, I don't remember testing this specifically, but I
can't think of any reason it wouldn't work.  Note to self: test this.

The main difference between the HTTP and WS translator is how you
gracefully remove them from service in a clustered setup.  For HTTP you
"detach" from the load balancer and give it time for any active requests to
finish before stopping Apache.  For WS, you detach then issue a graceful
Apache stop (or restart), which tells the WS translator to kick off clients
as soon as all active requests are completed.  When all clients are
disconnected, the shut-down completes.


> Some background on the technology: even though some browsers don't
> support multipart/x-mixed-replace (most, other than IE, do at least
> for images -- it's used for simple webcam apps) we were far from the
> first to use it, and it's fairly trivial to implement on the client
> side.  FWIW, curl supports it, so I wouldn't be too surprised to find
> clients in the wild using it.
>

Yes, all good points.  I should have clarified that mixed/replace in
combination with XMLHttpRequest is the real issue here.  That specifically
was only ever supported by FF, and eventually deprecated.


>
> All that said, WebSockets is way better and if you write a new
> (future) client that uses the translator and multipart/x-mixed-replace
> for streaming then you are a bad person and you should feel bad. :)
>
>
And pinesol_green will blame you for stealing all the tux dolls.

-b
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20160921/a9c5bc67/attachment-0001.html>